Most generative AI ideas that reach a first conversation are about text, usually a chatbot or an email draft. The same technique also produces images, code, design candidates, audio and test data, and each of those uses works only when one particular check is in place. Choosing a use case is mostly a matter of knowing which check you are signing up for, and whether you can staff it.
Six patterns and the check behind each
What follows are patterns, not case studies. They describe what teams build and what they need to verify, and none of them reports a result from a particular company. The table gives the short version; the sections after it explain each row.
| Pattern | What the model produces | The check it depends on |
|---|---|---|
| Marketing assets | Image and video variants | Brand review and usage rights |
| Voice and audio | Narration in several languages | Voice rights and a native-speaker review |
| Code assistance | Code, fixes and test cases | Code review and the existing test suite |
| Design candidates | Shapes or layouts to evaluate | A simulation or engineering check |
| Personalised content | Descriptions and recommendations | Consent for the data and a fallback |
| Synthetic data | Artificial records for testing | Comparison with the real distribution |
Every row has the same shape. A model produces a draft, something else checks it, and a person or a downstream system accepts or rejects it. The model is the fast, variable part, and the checking is where reliability comes from, so most of the engineering time goes there.
Assets for marketing and voice for service
Image models turn one approved idea into variants across formats and styles, and reduce how much a team leans on stock photography. Take a saree label planning a Navratri campaign that has to run on its own site, two marketplaces and WhatsApp broadcasts in the same week. A generator can produce the fifty crops and variants in an afternoon. Volume is the easy part. Someone has to check brand consistency and the tool's usage terms and approve each asset before it goes out, and that afternoon's fifty variants take a person's whole next morning.
Audio follows the same logic. The same IVR script can be voiced in Hindi, Marathi and Kannada without booking three studios. The check is the right to use a voice, telling callers the voice is synthetic, and a native speaker reviewing each language before it goes live. The model's Kannada may be fluent and still sound odd to a customer in Mysuru.
Code, designs and simulations
Coding assistants suggest code, propose fixes and write test scenarios. Teams use them for boilerplate, unit tests and refactoring suggestions, which leaves engineers more time for design. The check is that generated code stays untrusted until it is reviewed and tested. It can look correct and still carry a wrong assumption, a library call deprecated two versions ago, or a gap in the OTP verification path. Code review and the test suite stay exactly where they are.
Generative models can also propose product shapes or layouts that engineers push through a simulation. The pattern is a loop in which the model proposes candidates, the simulation tests them, and the survivors seed the next round. Here the simulation decides, never the model. A generated bracket design that has not passed the structural check is only an idea, and it goes into the catalogue after the simulation says yes.
Personalised content and synthetic data
Product descriptions, recommendations and visuals can be tailored to a customer or a segment. The description of the same pressure cooker can read differently for a first-time buyer in Patna and for a repeat buyer who already owns two. The checks are which customer data goes into the prompt, whether the customer would expect it to be used that way, and what the page shows when the model fails or is slow. A product page that goes blank because a model timed out during the Diwali peak is worse than a plain description, so the plain description stays as the fallback.
Synthetic data is the least visible pattern and one of the most useful. A hospital chain can test new appointment software against artificial patient records, so no real patient's details sit in a test environment. The check is that synthetic data can still reproduce patterns from the original, and that it tends to miss rare cases. Validate it against the real distribution before trusting any test result built on it.
When rules are the better tool
Some problems have fixed answers, and a model only adds variation to them. The estimator BizHues built for Nebula Digital Accessibility is an example. It is a rules engine: guided scoping answers go in, and effort by role and three package options come out. The same inputs give the same result, and anyone can read the logic and change it.
The same holds for much of what businesses ask for first. GST on an invoice, an EMI schedule, which warehouse serves which pin code and whether a KYC document set is complete are all rules, and rules should stay rules. Our piece on when a trained model earns its place over rules sets out how to test that boundary with your own records.
- Same input gives the same output
- Logic can be read, tested and audited
- Fits calculations, pricing, routing, validation
- Handles open-ended text, images, audio
- Output varies between runs
- Needs evaluation and human review
Many features use both. Rules decide, and the model drafts wording or media.
Where generative AI projects go wrong
The first mistake is picking a use case because it demos well, with nobody in the business who owns the problem it solves. The second is skipping evaluation, so quality becomes whatever the person who happened to look thought of it. Pointing a model at something a formula would do exactly is the third.
Review is the most underestimated cost. Generated volume moves the bottleneck to the person who approves, and if that person has a day job, the queue grows quietly. Put the review step into the design from the start, as in the review gate around generated text, and staff it before launch.
- 01Request
- 02Model generatesdraft output
- 03Automated checksformat, banned terms
- 04Person approvesbefore release
The automated checks catch format problems so the reviewer spends time on judgement.
The last is ignoring cost per request until usage grows and the finance head asks why the API bill has jumped. Estimate it per request on day one, using realistic input sizes.
Picking your first use case
- Write the problem in one sentence, including who will use the output.
- Ask whether rules would solve it. If they would, use rules.
- If a model is needed, collect ten real examples of a good output and ten of a bad one.
- Name the person who reviews, and decide what happens when the model is unavailable.
Do step two before anything else, because it removes the cases where a model was never needed. Then bring the sentence, the twenty examples and the reviewer's name to the first conversation about generative AI work. What decides the project at that stage is whether the check can be staffed, and those three things answer it.
