AB-731: Choosing Generative AI Solutions and Model Strategies

Introduction

Leaders should choose the least customized generative AI approach that satisfies the business requirement and its control needs. Start with a packaged solution when the workflow is common and the product already provides the required experience. Use a pretrained model when the organization needs a custom application or workflow but the model's existing capabilities are sufficient. Add grounding when responses must use current, private, or domain-specific information. Consider fine-tuning only when repeatable behavior, style, or task performance cannot be achieved reliably through product configuration, prompts, examples, or grounding.

This order is a decision framework, not a maturity ladder. More customization is not inherently better. Additional customization can increase design, evaluation, security, operational, and change-management responsibilities. The right choice is the option that meets measurable quality, risk, latency, scale, and ownership requirements with justified complexity.

Architecture Overview

A generative AI solution is more than a model. It combines a user or system interaction, instructions, information context, model inference, controls, evaluation, and an operating process. The selection decision therefore has two levels:

1. Solution level: Decide whether an existing product experience can deliver the outcome or whether the organization needs to assemble a custom solution.
2. Model strategy level: For a custom solution, decide whether a pretrained model is sufficient and whether grounding or fine-tuning is justified.

These levels should not be collapsed. A packaged solution may already include models, context handling, security controls, and user experiences that the customer would otherwise have to design. Conversely, choosing a model does not define the complete application, its data permissions, or its operating model.

The decision starts with a written requirement: the user, task, desired output, required information, acceptable error, consequence of failure, expected demand, and accountable owner. Without that requirement, model comparisons tend to reward impressive demonstrations instead of business fit.

Core Solution and Model Options

Packaged generative AI solution

A packaged solution provides a ready-to-use experience for a defined class of work. It is usually the strongest starting point when the process resembles a common productivity or business scenario, users need familiar interfaces, and the product's supported configuration and governance controls meet the requirement.

The main benefit is not merely speed to purchase. The organization avoids building and operating parts of the experience that the vendor already supplies. The tradeoff is that workflow behavior, integration, differentiation, and model-level control may be constrained by the product.

Choose this path when:

• The desired task maps closely to supported product capabilities.
• Standard configuration can meet data, identity, compliance, and user-experience requirements.
• Faster adoption matters more than unique model behavior.
• The organization does not gain meaningful advantage from owning a custom application stack.

Do not reject a packaged option simply because it offers less technical control. Reject it when a documented business or control requirement cannot be satisfied.

Pretrained model in a custom solution

A pretrained model is trained before deployment and can perform many downstream tasks without additional model training. It is appropriate when the organization needs a custom interface, workflow, integration, or orchestration layer but can obtain acceptable results through model choice, instructions, prompts, examples, and application controls.

Microsoft Foundry provides a catalog and lifecycle capabilities for discovering, evaluating, customizing, deploying, and operating models. The Microsoft Foundry Models overview emphasizes that model choice includes tradeoffs across capability, deployment, evaluation, customization, and operational needs.

Choose this path when:

• The workflow is distinctive enough to require a custom application or integration.
• A general-purpose model performs the required reasoning or generation task adequately.
• The application can supply effective instructions, validation, and human review.
• The organization is prepared to own application security, testing, monitoring, and lifecycle decisions.

Model benchmarks can narrow the field, but representative task evaluations should decide the fit. A model that leads a general benchmark may still be unsuitable for the organization's language, response format, latency target, risk tolerance, or deployment constraints.

Grounded model experience

Grounding supplies relevant context to a model at response time. Use it when a response must reflect information that is private, organization-specific, frequently updated, or outside the model's general learned knowledge. Examples include current policies, approved product documentation, case records, or controlled knowledge collections.

Grounding changes the information available for a request without retraining the base model. It can improve specificity and factual relevance, but it does not guarantee correctness. Microsoft's grounding data design guidance treats source quality, freshness, retrieval, permissions, and evaluation as design concerns.

Choose grounding when:

• Answers depend on current or proprietary facts.
• Users should receive information within their existing access boundaries.
• The source content can be prepared, governed, retrieved, and refreshed.
• The response can be evaluated for both retrieval quality and answer quality.

Grounding is often combined with a pretrained model; it is not necessarily a separate replacement for one. Detailed retrieval-augmented generation (RAG) architecture is a distinct design topic, but the selection principle is simple: use grounding for knowledge that should be supplied at request time rather than embedded through additional training.

Fine-tuned model

Fine-tuning performs additional training on a pretrained model using a task-specific dataset. It can be appropriate when the required improvement concerns consistent behavior, output structure, style, or specialized task performance and simpler controls have not produced acceptable results.

Fine-tuning should follow evidence, not preference. Microsoft's conceptual fine-tuning overview identifies method, model, training-data, evaluation, deployment, and cost considerations. Method-specific instructions must then match the selected model and deployment; a supervised fine-tuning procedure does not establish support for every other training method. The organization must be able to assemble suitable examples, evaluate a candidate against a baseline, and maintain the resulting model asset.

Choose this path only when:

• Representative evaluations show a material and repeatable gap with the pretrained approach.
• The desired change is primarily model behavior, not access to changing facts.
• A sufficiently representative and appropriately governed training dataset exists.
• The expected improvement justifies training, evaluation, deployment, monitoring, and update responsibilities.

Fine-tuning is usually a poor substitute for grounding. Training on a fact does not provide a dependable mechanism for keeping that fact current, applying per-user permissions, or citing the retrieved source. A solution may use both grounding and fine-tuning when it has separate knowledge and behavior requirements, but each should have its own justification.

How the Options Work Together

The four options form a set of composable choices rather than four mutually exclusive products. A custom application can use a pretrained model with grounding. A fine-tuned model can also receive grounded context. A packaged product may internally apply several of these techniques while exposing only supported configuration to the customer.

The most useful selection sequence is:

1. Test for product fit. Determine whether a packaged solution already supports the users, workflow, information boundaries, and required controls.
2. Establish a pretrained baseline. For a custom need, test suitable pretrained models with representative prompts, examples, and evaluation cases.
3. Add required knowledge context. If failures come from missing, private, or changing information, introduce grounding and evaluate retrieval as well as generation.
4. Isolate a behavior gap. If failures persist because the model does not perform the task or format consistently, test whether fine-tuning addresses that specific gap.
5. Compare the complete solutions. Evaluate quality, safety, latency, scalability, security, maintainability, adoption fit, and operational ownership—not only model output in a demonstration.

This sequence avoids paying the complexity cost of customization before the team knows what problem the customization solves.

Decision Matrix for Generative AI Selection

The matrix identifies a starting point, not an automatic approval. Security, privacy, responsible AI, accessibility, integration, service availability, and organizational readiness remain part of every option.

Design Considerations

Define acceptance criteria before comparing models

Build a representative evaluation set from the real task and define what an acceptable response looks like. Include routine cases, ambiguous inputs, high-consequence cases, and situations where the system should decline or escalate. Evaluate the complete experience, including instructions and context, because isolated model scores do not reveal how the deployed workflow behaves.

Microsoft's model selection and evaluation training describes evaluation across dimensions that include quality, safety, cost, and performance. Leaders should require traceable evidence for the dimensions that materially affect their use case.

Separate knowledge problems from behavior problems

When an answer lacks an organizational fact, the likely need is better context or retrieval. When the answer contains the right facts but repeatedly violates an expected structure or task pattern, model choice, prompt design, examples, or fine-tuning may be relevant. Diagnosing the failure before choosing the intervention prevents unnecessary training and weak data architectures.

Include the control boundary

Selection criteria should state which information the solution may access, where processing occurs, who can use it, how outputs are reviewed, and how incidents are handled. A technically capable option is not suitable when its supported deployment or governance model cannot satisfy those conditions.

Plan for change

Models, services, and packaged capabilities evolve. Preserve evaluation cases and decision records so the organization can reassess a choice when requirements, available models, or vendor capabilities change. Avoid coupling a business process to one implementation detail when a stable interface or controlled configuration can preserve flexibility.

Common Selection Mistakes

Starting with the most customizable option

Customization creates obligations as well as flexibility. Begin with the business gap and add only the control necessary to close it.

Treating grounding and fine-tuning as interchangeable

Grounding supplies context at response time; fine-tuning adapts model behavior through additional training. Confusing them can produce stale knowledge, weak permission controls, or an unnecessary model-maintenance burden.

Selecting from one impressive prompt

A demonstration is not representative evaluation. Use a test set that reflects actual users, inputs, failure consequences, and output criteria, then compare candidates against the same baseline.

Comparing models without comparing solutions

The model is one component. User experience, workflow integration, data preparation, identity, security, evaluation, monitoring, support, and adoption determine whether the complete solution can deliver value.

Ignoring operational ownership

A custom or fine-tuned approach needs named owners for data, application behavior, evaluation, deployment, monitoring, updates, and retirement. If the organization cannot assign those responsibilities, a less customized option may be the more sustainable choice.

Certification Relevance

For Microsoft Certified: AI Transformation Leader, the important capability is business-led selection. A leader should be able to connect a requirement to a solution category, explain when a pretrained model is sufficient, distinguish grounding from fine-tuning, and demand evidence that additional customization creates measurable benefit.

That reasoning starts with the opportunity framing in AB-731: Generative AI Foundations and Business Value for Leaders. After selecting a viable strategy, leaders can examine the associated economic model in AB-731: Generative AI Cost Drivers, Tokens, and ROI and explore platform-specific choices in AB-731: Matching Business Needs to Microsoft Foundry and Foundry Tools.

Conclusion

Choose a packaged solution for a well-supported common workflow, a pretrained model for a custom experience whose base capabilities meet the task, grounding for current or controlled knowledge, and fine-tuning for an evidenced behavior gap that simpler methods cannot close. Combine these approaches only when separate requirements justify each component.

The durable leadership principle is to earn complexity through evidence. Define the outcome and controls, establish a baseline, diagnose the gap, and select the least customized architecture that meets measurable business and operational requirements.

Authoritative Sources

• Microsoft Foundry Models overview
• Customize a model with fine-tuning
• Fine-tuning models in Microsoft Foundry overview
• Grounding data design for AI workloads
• Select, deploy, and evaluate Microsoft Foundry models

Related Reading

• Prerequisite: AB-731: Generative AI Foundations and Business Value for Leaders
• Next: AB-731: Generative AI Cost Drivers, Tokens, and ROI
• Deep Dive: AB-731: Matching Business Needs to Microsoft Foundry and Foundry Tools