Choosing AI models without getting lost in the hype

A request for “all AI models” sounds straightforward until the first distinction is made: there is no stable, complete public list of every AI model in existence. Thousands of models are released, fine-tuned, renamed, retired, privately deployed, or available only inside a company product. A single provider can expose several generations, specialised variants, regional versions, preview models, hosted copies and customer-specific fine-tunes at the same time. Any page that claims to be the final universal directory is already incomplete.

A catalogue cannot be frozen

The useful goal is different. It is to build a map that helps a reader recognise the major families, understand the role of less familiar players, and decide which model deserves testing for a real job. This article therefore treats the market as it stood on 1 July 2026, while making the limits clear. It covers public model families, the platforms through which they are sold or deployed, and specialist systems that matter even when they are not famous consumer chatbots.

The most visible names are often product brands rather than model names. ChatGPT is an application. Claude is both a product name and a family name. Copilot is an umbrella for several Microsoft products and, increasingly, a picker for models from more than one provider. Gemini refers to a family of Google models as well as consumer and workplace products. That naming overlap creates much of the confusion before a user has even typed a prompt.

The market is moving from a shortlist of famous chatbots to a layered supply chain. At the top sit frontier general-purpose models. Under them are cost-focused variants, reasoning models, coding models, image and video generators, speech systems, embedding models, rerankers, safety classifiers and open-weight models designed for private deployment. The right model for a company search system may never be the right model for a legal drafting tool, and neither may be the right system for a mobile app.

The pace of change is not a cosmetic problem. Google’s documentation, for example, shows active Gemini families, previews and retirements; Anthropic publishes model availability and deprecation guidance; Microsoft’s Foundry catalogue aggregates models from many suppliers. A model choice is therefore not a one-off procurement decision. It is an operating decision that needs a review cycle, migration plan and evidence trail.

A sensible reader should resist two bad habits. The first is treating one benchmark chart as a league table for every task. The second is treating a familiar chatbot as the underlying model itself. Both errors make buyers overpay, miss specialist tools and underestimate operational risks. The rest of this guide starts with the vocabulary that separates a model from the software wrapped around it.

The layers hidden behind a familiar chatbot

A model is the statistical engine that predicts, classifies, generates or transforms data. A chatbot is usually an interface around one or more models. It may add web search, file handling, memory, safety filters, workflow rules, identity controls, billing, connectors and analytics. The same branded assistant can route different requests to different models without making that distinction visible to the user.

This matters because public discussion often uses model, product and provider as interchangeable labels. “I use Copilot” does not reveal whether a person means Microsoft 365 Copilot, GitHub Copilot, Copilot Studio, a Windows feature or a model selected through Microsoft Foundry. “I use ChatGPT” does not reveal whether the work relies on a general chat model, a reasoning mode, a coding workflow, a web-connected tool or an image generator. A procurement team that does not separate those layers cannot compare alternatives properly.

A foundation model is a broad model trained on large datasets and adaptable to many downstream tasks. A language model is usually strongest with text, though modern systems frequently accept images, audio, video, documents and code. A multimodal model can work across more than one data type. An embedding model converts content into numerical vectors used for similarity search. A reranker sorts retrieved documents by relevance. A guardrail model judges whether an input or output violates defined policy. These are complementary components, not rival chatbots.

An agent is another layer. It combines a model with instructions, tools and a loop that can plan, call software, inspect results and continue working. Tool use can include database queries, calendar actions, web search, code execution or internal APIs. An agent may appear intelligent because the whole system can act, but its success still depends on the quality of the underlying model, tool permissions, retrieval, workflow design and human controls.

The practical implication is simple: compare a full system against another full system when choosing a workplace product, but compare models against models when building software. A model can be excellent at drafting text and poor at following a rigid schema. A consumer assistant can be pleasant to use while offering insufficient data controls for an employer. The decision unit must match the actual problem, not the marketing label.

Microsoft’s current documentation illustrates the overlap. Its Foundry catalogue spans providers such as Azure OpenAI, Mistral, Meta, Cohere, NVIDIA and Hugging Face, while some Copilot experiences allow model selection or bring-your-own-model configurations. That is why “Copilot versus Claude” is often the wrong comparison; one is frequently a product layer, while the other may be a model family accessed directly or through a cloud platform.

A useful map of the AI model market

The first group consists of frontier proprietary general-purpose models. OpenAI, Anthropic, Google and xAI compete here, joined by commercial offerings from Amazon and other cloud firms. These systems tend to be delivered through hosted products or APIs. Their providers control the weights, infrastructure, safety architecture and release cadence. Customers gain fast access to strong capabilities but accept dependence on a vendor’s pricing, policies and technical roadmap.

The second group is commercial but more deployment-flexible. Mistral, Cohere, IBM and some regional suppliers offer hosted models, selected open-weight releases or both. Their appeal is often practical rather than theatrical: predictable enterprise integration, retrieval support, private hosting options, language coverage, cost control or compatibility with established cloud infrastructure. A model does not need to dominate social-media comparisons to be a strong enterprise choice.

The third group is the open-weight ecosystem. Meta’s Llama, Alibaba’s Qwen, DeepSeek, many Mistral releases, IBM Granite variants and a long tail on Hugging Face allow developers to download weights or use community-hosted versions under varying licences. “Open weight” means the trained parameters are available. It does not automatically mean the model is open source under an OSI-approved licence, free of commercial restrictions, easy to operate or safe to deploy without testing.

The fourth group is specialised AI. It includes text embedding models, rerankers, speech recognition, translation, document extraction, image generation, video generation, biology models, forecasting models and safety classifiers. These systems can be less glamorous than large chat models but frequently have clearer business value. For a search application, retrieval quality often matters more than another marginal gain in general conversation.

The fifth group is the infrastructure layer: Amazon Bedrock, Microsoft Foundry, Google Vertex AI, NVIDIA NIM, Hugging Face, Together AI, Fireworks, Groq, Replicate and similar services. These companies may host or serve models rather than train every model themselves. Their role is crucial because they determine availability, regional deployment, throughput, observability, governance and model-switching friction.

A final category is local and edge AI. Small models run on laptops, phones, workstations, private servers and embedded devices. They are useful when connectivity, privacy, latency or cost makes an external API unsuitable. They also create a different set of obligations: hardware sizing, model quantisation, patching, evaluation and security are now the customer’s responsibility rather than the provider’s.

The clearest mental model is a six-part map: frontier, commercial, open-weight, specialist, platform and edge. A provider can appear in more than one category. Amazon is both a model developer through Nova and a platform through Bedrock. Google supplies Gemini models and cloud tooling. Microsoft provides applications, a cloud catalogue and access to third-party models. Meta develops Llama but also distributes it through partners.

Names, versions and deprecations decide more than headlines

Model names are not product categories. They are versioned technical identifiers, often with suffixes that signal speed, size, reasoning behaviour, modality, safety tuning or deployment status. A “Flash,” “Lite,” “Mini,” “Haiku,” “Small,” “Nano,” “Turbo,” “Pro,” “Reasoning,” “Coder,” “Instruct” or “Preview” label usually points to an intended trade-off. It does not establish universal quality.

A smaller, faster model may be the better production choice for routing, classification, extraction, support triage or high-volume summarisation. A larger reasoning model may be appropriate for complex coding, research synthesis, legal analysis under professional review or planning tasks that justify higher latency and token cost. Model selection starts with workload shape, not prestige.

Version control matters because providers retire models. Google’s documentation has shown older Gemini versions being shut down and directs developers toward replacements. Anthropic explicitly maintains deprecation guidance. DeepSeek’s API documentation also identifies model names scheduled for replacement or retirement. An application hard-coded to a dated model label can fail, change behaviour or become expensive without a technical migration process.

Preview labels deserve extra caution. A preview may be useful for experimentation, evaluation and early design, but it may have a limited availability window, changing performance, altered pricing or incomplete compliance commitments. Product teams should avoid making a preview model the single point of failure for a revenue-critical workflow unless they have a documented fallback and have accepted the contract terms.

The version number alone does not settle capability. A later model may be cheaper but more constrained. A newer coding model may outperform an older generalist on repositories but not on customer-facing writing. A later multimodal model may accept more formats but require a different prompting style or impose lower rate limits. Release notes are part of the specification, not optional reading.

The right internal record is a model card for your own use: provider, exact model identifier, region, date tested, tasks tested, prompts, tools allowed, temperature or reasoning settings, cost, latency, safety observations, known failure modes, data policy and replacement plan. That record is more useful than a screenshot of a chatbot answer because it lets a team reproduce, audit and revise a choice.

Model names also help reveal deployment assumptions. “Instruct” normally indicates a model tuned to follow commands. “Base” is often intended for fine-tuning or research. “Embedding” denotes vector generation. “Rerank” denotes relevance scoring. “Guard” or “Guardian” signals safety evaluation. “Vision,” “Audio,” “Image” or “Video” identifies a modality. Treat the label as a clue, then verify the current documentation before relying on it.

The model map at a glance

A practical directory by role rather than popularity

The table is a route map, not a performance ranking. A model family may appear in more than one row because capabilities, deployment choices and business roles overlap. The right starting point is the role you need to fill, then the models and platforms that plausibly meet it.

A user who needs a personal writing assistant will likely begin with consumer products. A developer building a regulated application starts with the platform, data controls and evaluation plan. A search team starts with embeddings and reranking. A company with strict data residency requirements may begin with self-hosting or a cloud region before it compares headline benchmark performance.

The directory also exposes an uncomfortable truth: a famous chatbot is a thin slice of the market. The less visible model families often do the work behind document search, voice transcription, support routing, fraud review, translation, forecasting, code completion and safety screening. The AI model market is broader than the conversation interface through which most people encounter it.

ChatGPT and OpenAI’s model families

OpenAI remains one of the most visible names because ChatGPT made general-purpose AI familiar to hundreds of millions of people. Yet ChatGPT should be treated as an application environment, while OpenAI’s API and model line are the development-facing layer. The provider describes its API offering as a set of frontier models with advanced intelligence and multimodal capability, but users should still inspect the current model documentation, pricing and product terms before committing a workflow.

The OpenAI family is commonly used for writing, analysis, software development, structured output, image understanding, tool calling and agent-style workflows. Different model variants are normally aimed at different points on the quality-speed-cost curve. The central question is not whether an OpenAI model is “best”; it is whether a particular model version is best enough for a defined task at an acceptable operating cost.

For personal users, ChatGPT’s advantage is the surrounding product: a familiar interface, file support, conversation history, tool integrations and a broad range of capabilities. For developers, the decision has more dimensions: latency, context capacity, structured-output reliability, content filtering, regional service requirements, usage caps, evaluation controls and the consequences of a provider update.

OpenAI is especially relevant where a team wants a generalist model that can move across text, code and visual inputs without building a patchwork of separate vendors. That simplicity is valuable, but it should not erase the need for comparison. A focused reranking model may perform better inside a retrieval pipeline. A local model may be more suitable for confidential offline work. A smaller hosted model may lower costs for routine extraction by an order of magnitude relative to a frontier reasoning model.

Do not confuse model intelligence with factual authority. Even a highly capable model can invent a source, omit a condition in a contract, misread a spreadsheet or confidently present an outdated statement. Web-connected workflows, retrieval systems, citations, source verification and human review are design choices that sit above the model. They should be selected according to the harm caused by a wrong answer.

A useful OpenAI test set should include your own documents, edge cases, vague requests, adversarial instructions, multilingual content, formatting constraints and known-answer questions. Test both the final answer and the path to it: tool calls, citations, formatting, refusal behaviour, cost and time. That prevents a common mistake in which a model is chosen after one impressive demo but fails under volume, ambiguity or real data.

Claude’s deliberately compact family

Anthropic’s Claude family is often praised for writing, analysis, long documents, careful instruction following and coding, though those traits should always be tested on the user’s own work. Anthropic presents its model selection framework around capability, speed and cost, a useful reminder that there is no single optimum across workloads. Its public documentation also exposes the fact that model availability and retirement are living operational concerns.

Claude’s naming convention has historically used a compact hierarchy, with higher-capability variants aimed at demanding tasks and smaller variants aimed at speed and cost. That arrangement is easier to understand than sprawling catalogues, but it can tempt buyers to select the most expensive option by default. A high-end model should earn its place through an evaluation result, not through the emotional comfort of buying the premium tier.

Claude is a serious candidate for teams that value nuanced prose, long-form analysis, code review, document work and predictable conversational behaviour. It is also available through more than one channel, including direct access and certain cloud platforms. The route matters because the billing relationship, data boundary, regional availability, logging and governance controls may differ even when the underlying model family is similar.

The model’s apparent restraint can be an advantage or a limitation, depending on the task. In high-risk domains, a system that notices uncertainty and resists unsupported speculation may save a reviewer time. In fast ideation, a more expansive model may feel more productive. The solution is not to declare one personality superior. It is to decide which failure mode is more expensive for the job: an overconfident invention, a needless refusal, a vague answer or a slow response.

Anthropic’s model documentation differentiates models and offers a Models API to discover currently available identifiers. That is a practical detail with wider meaning: applications should obtain model availability through supported mechanisms, maintain version pinning where offered, and treat retirement notices as production events.

Claude should be evaluated alongside alternatives in the exact environment where it will run. A model that is exceptional in a clean chat window may behave differently once it receives retrieved documents, functions, policy instructions, system prompts, large tables or lengthy conversations. Prompt examples from a provider’s documentation are useful for learning the interface, but your own task distribution is the only benchmark that determines commercial value.

Gemini across Google’s consumer and developer stack

Gemini is not one thing. It is a family of models, a consumer assistant, a developer API, a workplace feature set and a cloud capability. Google’s current model documentation lists multiple families for general use, lightweight workloads, audio and generative media, while some older variants have been retired. This breadth is an advantage for organisations already invested in Google’s productivity and cloud ecosystem, but it makes careful naming essential.

The key distinction is between a general-purpose reasoning model and an operationally efficient model. Google positions some Flash and Flash-Lite variants for low latency, high-volume processing and agentic loops, while Pro variants are aimed at more difficult reasoning, code, large datasets and long-context work. Those positions should guide a first test, not replace one.

Gemini’s multimodal direction is particularly important. Many current systems accept text, images, audio, video and PDF-like document inputs. That can reduce the need to pre-process material into separate pipelines, but it also raises quality questions. A model that can ingest a document does not necessarily extract every table correctly, understand a scanned page, respect a chart’s visual encoding or preserve a legal qualifier buried in a footnote.

Google also provides specialised models such as embeddings and research-oriented agentic offerings. An embedding model is not a chatbot; it turns content into vectors so systems can retrieve semantically similar material. That can be more valuable than a large general model where a company needs search, recommendation or retrieval-augmented generation. Google documents Gemini Embedding specifically for semantic search, document retrieval and recommendation use cases.

For enterprises, the practical attraction may be integration with Google Cloud, Vertex AI, Workspace controls, identity, storage and data tooling. The practical risk is assuming that a consumer-facing Gemini feature has the same controls, contractual terms or regional behaviour as a cloud deployment. The interface where staff use an AI feature is not a substitute for a data-processing and security review.

A sound Gemini evaluation should separate text quality, multimodal understanding, long-document behaviour, extraction accuracy, tool calling and response speed. It should also distinguish between a model’s raw answer and the quality of the surrounding application. A model can be technically capable while the selected product tier lacks the audit trail, access controls or governance features needed by the organisation.

Copilot is a product layer, not a single model

“Copilot” has become one of the most overloaded words in AI. It can refer to Microsoft 365 Copilot, GitHub Copilot, Copilot Studio, Copilot for Security, Copilot features in Windows, or product-specific assistants in business software. It is usually more accurate to call Copilot an experience layer than to call it a single AI model.

This distinction helps prevent bad comparisons. GitHub Copilot is principally a coding product embedded in developer workflows. Microsoft 365 Copilot is a workplace productivity layer tied to documents, mail, meetings and organisational data. Copilot Studio is a building environment for assistants and automations. Microsoft Foundry is a development and model platform that can expose models from Microsoft, OpenAI and external suppliers. Each has different controls, inputs, permissions and risk profiles.

Microsoft’s current documentation describes Foundry’s model catalogue as a hub for hundreds of models across providers, including Azure OpenAI, Mistral, Meta, Cohere, NVIDIA and Hugging Face. It also documents certain Copilot environments where users can select or configure models from providers such as OpenAI, Anthropic, Google and xAI. The label “Copilot” therefore tells you little about the exact model until you inspect the product and configuration.

For organisations already operating in Microsoft 365 and Azure, the attraction is obvious: identity, permissions, compliance tooling, data connectors, observability and familiar administration can lower the implementation burden. Yet integration does not erase the principle of least privilege. An assistant connected to a broad document estate may retrieve sensitive material that the requester should not use in the context of a particular task, even where technical permissions are valid.

GitHub Copilot has a distinct evaluation challenge. The question is not merely whether it generates plausible code. It is whether it improves repository-level productivity without increasing defects, insecure patterns, licensing uncertainty or review burden. Model choice should be tested against real codebases, unit tests, dependency policies, infrastructure conventions and secrets-handling rules.

A buyer should ask four questions whenever someone proposes “Copilot”: which product, which underlying model or models, what data can it access, and what actions can it perform? Those four questions turn a vague brand conversation into a technical and governance decision. They are equally useful when evaluating ChatGPT Enterprise, Claude for Work, Gemini for Workspace or any branded assistant.

Grok and xAI in the frontier-model conversation

xAI’s Grok family is a growing part of the hosted-model market. Its documentation distinguishes general chat, coding, image, video and voice capabilities, and positions current Grok models for configurable reasoning and tool use. The provider’s model page identifies Grok 4.3 for broad general use and Grok Build for coding-oriented work, while the wider platform offers dedicated media capabilities.

Grok deserves attention because it illustrates a broader shift: frontier providers are no longer selling one text model. They are assembling portfolios of reasoning models, coding systems, media generators, APIs and agent tooling. That makes product comparisons harder, but it also creates useful options for developers who want to separate a coding task from a general customer-support task or an image workflow.

The first thing to test is whether Grok’s style and behaviour fit the intended audience. A model can feel lively and direct in an exploratory setting but be unsuitable for a regulated customer interaction, a conservative corporate knowledge base or a sensitive workplace workflow. Tone is an operational property when the model speaks on behalf of an organisation.

The second issue is tool use. xAI documents function calling and structured outputs, features that are central to building workflows that do more than answer questions. Structured output helps a model return data in a required format. Function calling lets it request actions from external software. Both capabilities are powerful but do not remove the need for permission design, validation and logging. A model should never be allowed to execute a consequential action merely because it produced a syntactically valid request.

The third issue is state. xAI’s Responses API documentation indicates that interactions may be stateful by default, with stored request and response history unless a developer selects local storage behaviour. That kind of implementation detail matters for privacy reviews, records management and customer disclosures.

For buyers, Grok belongs in a focused evaluation if its current performance, pricing, tools or integrations match the workload. It does not need to be treated as a cultural alternative to other chatbots. A serious model review compares outcomes, costs, controls and failure modes rather than brand identities.

Amazon Nova and the Bedrock marketplace

Amazon plays two roles in AI selection. It develops the Amazon Nova family and runs Amazon Bedrock, a managed platform through which customers can access many foundation models. This combination is useful for organisations that want to keep model choice within AWS account structures, security controls, billing systems and regional cloud deployment. Bedrock’s current documentation describes hundreds of foundation models and the ability to change models without rewriting an entire application architecture.

Nova itself covers understanding, creative and speech-oriented categories. AWS describes Nova’s understanding models as multimodal and presents higher-capability variants for more complex work, while smaller options target more economical use. The important point is not the brand hierarchy; it is the ability to match a model to a workload and then measure the outcome on AWS infrastructure.

Bedrock can reduce vendor-switching friction, but it does not make different models identical. Providers retain different licences, safety behaviours, context limits, pricing structures and model-specific request formats. A team that uses a common platform still needs model-specific evaluation. It also needs to understand whether a given model is available in the required AWS Region, whether it supports on-demand use or requires provisioning, and what retention or logging settings apply.

AWS documentation also highlights customisation pathways such as supervised fine-tuning, reinforcement fine-tuning and distillation for selected models. Fine-tuning should not be a reflex. It is useful when a model repeatedly misses a stable, narrow task despite good prompting and retrieval. It is wasteful when the real problem is poor source documents, incomplete permissions, unclear workflow rules or a lack of evaluation data.

A model marketplace is a governance convenience, not a substitute for architecture. Enterprises should still separate experimental projects from production workloads, restrict credentials, log tool actions, set rate limits, monitor cost, test failure paths and preserve the ability to route traffic to an alternative model. That is especially important when an application becomes customer-facing or handles sensitive data.

Amazon Nova and Bedrock are strong candidates for teams already deep in AWS. For a smaller company with no AWS estate, the platform overhead may outweigh the benefits. The correct comparison includes cloud fit, engineering skills, data location, procurement terms and operating model—not only the answer quality in a browser demo.

Llama and Meta’s open-weight model ecosystem

Meta’s Llama family is one of the most influential open-weight model ecosystems. The public Llama site and Meta announcements identify Llama 4 variants such as Scout and Maverick, with native multimodal capability and mixture-of-experts design. The models can be downloaded and deployed through partners, but their availability does not turn them into unrestricted public-domain software. Open weights and open-source licensing are different legal and operational concepts.

Llama is attractive for organisations that want more control over inference, fine-tuning, deployment or data boundaries than a closed hosted API may offer. It is also a major base for community tooling, quantised releases, local runtime environments and third-party platforms. That ecosystem can lower the cost of experimentation, but it moves responsibility toward the user.

The first responsibility is licensing. Meta’s terms can impose conditions, and model users must read the licence for the exact version they plan to distribute, fine-tune or include in a product. A developer should not rely on casual statements that Llama is “fully open source” without reading the governing terms. Commercial freedom, redistribution rights and user-scale restrictions are legal questions, not social-media labels.

The second responsibility is deployment. A local or self-hosted Llama model needs hardware, serving software, patch management, rate limits, access controls, monitoring and security. Quantisation may make a model fit on a smaller machine, but it can affect quality and may change the behaviour most relevant to the task. A quick local demo is not a production readiness assessment.

The third responsibility is safety. Meta publishes safety tools including Llama Guard and related protections, but a guard model is only one part of a defence system. It must be configured, evaluated and paired with workflow controls. A content classifier cannot decide whether a proposed financial action, medical statement or employee decision is appropriate in the real-world context.

Llama should be on the shortlist where data control, customisation and private deployment are core requirements. It may not be the best choice where a team lacks infrastructure capability or needs the simplest managed experience. The economic advantage of open weights can disappear if serving, engineering, security and support costs are ignored.

Mistral’s European commercial and open-weight blend

Mistral occupies a distinctive place in the market by combining hosted commercial models with open-weight releases and a European identity that appeals to some organisations assessing data sovereignty and regional supplier diversity. Its documentation presents a broad model overview, selection guidance and deployment options across providers. Mistral explicitly describes its portfolio as including both open-weight and commercial large language models.

The company’s model range includes general language models, code-oriented systems, OCR and multimodal offerings. Its model cards also demonstrate why version management matters: older models can carry stated deprecation dates and named replacements. A model comparison that ignores deprecation policy is incomplete because continuity is part of technical quality.

Mistral is often considered by teams looking for a balance between strong general capabilities, potential deployment flexibility and an alternative to the largest US platform providers. Its European footprint may be relevant to procurement, but a geographic label alone does not establish compliance. Buyers still need to examine the exact hosting location, data-processing terms, sub-processors, retention settings and integration route.

The open-weight side of Mistral’s portfolio is especially relevant for developers deploying models within their own environment. It supports experimentation with inference stacks, quantisation and fine-tuning while retaining the option of managed usage for other workloads. That flexibility can reduce lock-in, but it increases the number of decisions a team must make about model governance.

For document-heavy workflows, Mistral’s OCR and document-oriented capabilities should be tested against actual scans, layouts, languages, handwriting, tables and low-quality images. A general language model may produce a fluent explanation of a document while silently dropping a column or misreading an amount. Extraction accuracy must be measured at field level, not judged by whether a summary sounds coherent.

Mistral belongs on the map not simply as a “European ChatGPT alternative,” which is too shallow a description. It is a provider with a mixed commercial and open-weight strategy, a growing model catalogue and practical relevance for teams that value choice in deployment. The right question is whether its current models outperform or simplify the intended workflow after all operating costs are counted.

Qwen’s broad and fast-moving model range

Qwen, developed by Alibaba’s AI teams, has become one of the largest and most active open model families. It spans general language models, code models, vision-language systems, audio capabilities, safety models and community-oriented tooling. The Qwen3 release introduced a flagship mixture-of-experts model and positioned the family for coding, mathematics, general reasoning and tool use.

Qwen’s importance is partly technical and partly strategic. It gives developers outside the small circle of US frontier providers another large open-weight ecosystem to evaluate. It is widely distributed through Hugging Face, ModelScope, cloud providers and local runtimes, producing an extensive third-party tooling landscape. That breadth is useful, but it means the exact checkpoint, licence, quantisation and serving implementation must be recorded carefully.

The family is especially relevant for multilingual work and for teams that want to run or adapt models themselves. However, claims about multilingual strength should be tested in the target language and domain. A model may handle casual Slovak, Czech, English or German dialogue well yet struggle with legal terminology, regional product names, technical abbreviations or scanned documents. Language quality is task-specific rather than a universal badge.

Qwen also illustrates the growth of coding agents as distinct products. Qwen Code is presented as an open-source terminal agent built around Qwen models and is designed to work with repositories, tools and agent workflows. A coding agent should be assessed differently from a chat model. The key measures include test pass rate, correct use of repository conventions, secure handling of secrets, ability to stop when uncertain, quality of change explanations and review burden for engineers.

Safety models are another meaningful branch. Qwen3Guard is described as a specialised guardrail family for classifying prompts and responses by risk. Such systems are valuable in a layered approach, but a classifier should not be treated as a legal decision-maker or the sole protection against misuse. Policy, access control, audit trails, human escalation and system design remain necessary.

Qwen merits attention because it reveals how far the non-Western open model market has expanded. A serious technology strategy should not assume that the choice is limited to ChatGPT, Claude and Gemini. It should examine Qwen where private deployment, coding, multilingual work, open-weight experimentation or supplier diversification are material requirements.

DeepSeek’s reasoning and cost story

DeepSeek became a major point of reference because it combined strong reasoning claims, open releases and aggressive cost positioning. Its documentation now shows a changing API line, including newer V4 variants and scheduled deprecation of older chat and reasoner names. It also provides OpenAI- and Anthropic-compatible API routes, a practical detail that can reduce migration friction for developers.

The company’s R1 release drew attention for making a reasoning-oriented model and related distilled models available under the MIT licence. DeepSeek’s own materials describe reasoning behaviour and tool-use support, while its newer product pages emphasise large context and mixture-of-experts architecture. Those claims deserve testing, but the structural point is clear: reasoning is now a product category, not merely a capability hidden inside a general chat model.

Reasoning models typically spend more computation on a difficult prompt. That can improve results on mathematical, coding, planning or multi-step analysis tasks, but it can increase latency and token consumption. For routine classification or concise extraction, it may be unnecessary. A company that sends every request to a reasoning model may create slow and expensive systems without improving outcomes that matter.

DeepSeek should be evaluated on more than cost and benchmark headlines. Buyers need to review data routes, hosting options, legal terms, security posture, availability, output consistency and support. In high-stakes work, the question is not just whether a model reaches a good answer, but whether the surrounding deployment offers sufficient controls, traceability and recourse.

The availability of open weights creates opportunities for self-hosting and derivative work, but it also requires caution. A local deployment of a large reasoning model may demand expensive GPUs, careful serving infrastructure and extensive quality assurance. Quantised or distilled versions may be useful for constrained hardware, yet they may not reproduce the behaviour of the original model on complex tasks. A model name does not guarantee a comparable implementation.

DeepSeek is therefore relevant in two ways. It is a direct model option for teams willing to evaluate it, and it is a market signal that high-level reasoning, long context and open-weight deployment are no longer exclusive to a few providers. That broader competition benefits buyers, provided they replace hype with task-specific evidence.

Cohere’s enterprise retrieval focus

Cohere is less famous in consumer conversation but highly relevant in enterprise AI because its product catalogue includes generation, embeddings and reranking. That combination aligns with a central business problem: finding the right internal information before a language model writes an answer. Cohere documents its models as serving different use cases and makes Command, Embed and Rerank available through several platforms.

Embedding models turn documents, chunks, images or other inputs into numerical representations. Search systems use those vectors to identify material that is semantically similar to a query. Rerankers then examine candidate results and sort them more precisely. A high-quality reranker often improves an enterprise answer more than replacing one general chat model with another.

Cohere’s Rerank documentation is unusually direct about this role: the system compares a query with a list of documents and returns relevance scores. That may sound modest beside a reasoning model, but it is fundamental to retrieval-augmented generation. If retrieval brings the wrong clauses, policies or product records into the prompt, a brilliant language model may produce a polished answer to the wrong question.

Cohere is particularly worth testing for organisations with private knowledge bases, multilingual documents, search-heavy workflows and a need for controlled retrieval. The model selection task should include retrieval recall, ranking quality, citation accuracy, hallucination rate after retrieval, response latency and the ability to abstain when no adequate source exists.

A common mistake is to judge a RAG system by a few answers where the desired document happens to rank first. Better testing uses a labelled set of real queries, known relevant documents, difficult near-matches, stale policies, conflicting versions and queries that should return no answer. The retrieval layer needs its own scorecard before the generation model is compared.

Cohere’s position shows why the “best chatbot” debate is incomplete. Organisations do not simply need prose. They need systems that retrieve authorised information, distinguish current from obsolete documents, preserve citations, enforce permissions and present uncertainty. A strong retrieval specialist can be the most consequential model in the stack.

IBM Granite and enterprise-specialist models

IBM Granite is another model family that matters more in enterprise architecture than in public chatbot rankings. Granite spans language models, vision, speech, embeddings, time series and safety-oriented systems. IBM’s current documentation describes Granite 4.0 models using hybrid Mamba-2 and transformer architecture with mixture-of-experts variants, while Granite 4.1 extends dense models in several sizes.

The value proposition is clear for teams that care about deployability, smaller model options, enterprise tooling and model provenance. IBM also publishes models under Apache 2.0 in selected areas, including some vision and embedding releases. That is a useful contrast with model families that are downloadable but governed by custom licences. Licence clarity can be as important as model quality when a company intends to distribute, modify or embed a model in a commercial product.

Granite’s specialist branches deserve attention. Granite Vision targets document and visual extraction tasks. Granite Speech supports speech recognition and translation. Granite Time Series covers forecasting, classification and anomaly detection. These are not replacements for every general-purpose model. They are examples of a wider pattern: practical AI work often benefits from a focused model with measurable outputs rather than a giant conversational system asked to imitate a specialist tool.

Granite Guardian is another important category. IBM describes it as a model family and adapters for judging inputs and outputs against criteria such as jailbreak attempts, profanity and hallucinations related to tool calls or retrieval. It can be useful in layered safety systems, particularly where an organisation needs explicit policy checks rather than relying entirely on a foundation model’s default moderation.

The limitation is familiar: a safety model introduces its own error profile. It can over-block legitimate work or miss subtle risks. It needs local calibration, a documented policy and escalation routes. No guardrail model can compensate for allowing an AI system too much authority, too much data or too little human review.

IBM Granite should be considered where an organisation wants a broader collection of enterprise-oriented open and specialised models, particularly for private deployment, search, speech, document understanding or structured workflows. It also reminds buyers that the market is not a race to build the biggest chat model. It is a contest over useful, deployable systems across many task types.

The less visible companies that still matter

The AI market contains many suppliers that deserve evaluation in the right context even when they are absent from mainstream consumer discussions. AI21 Labs has focused on language technology and enterprise applications. Aleph Alpha has positioned itself around European language-model work and explainability themes. Writer has built enterprise-oriented generative AI products. Perplexity has developed answer-and-search experiences. NVIDIA supplies model-serving infrastructure and curated inference packages. Hugging Face operates a major model and dataset ecosystem. Visibility in a consumer chatbot race is not the same as relevance to a business architecture.

Some companies are model developers; others are platforms, hosts, tooling vendors or application builders. This difference matters. A platform that lets a team serve models from multiple providers may reduce infrastructure work. A model hub may offer thousands of checkpoints but provide little guarantee about quality or provenance. A vertical application may solve a narrow problem very well while revealing less about the underlying model.

Media AI adds another set of less familiar but important names. Stability AI, Runway, Luma, Pika, ElevenLabs, Suno and similar providers focus on images, video, voice or music. Their role is not interchangeable with a language model. A marketing department that needs motion graphics, voice narration or product imagery should evaluate output rights, consistency, safety controls, watermarking, regional rules and integration—not only whether a text chatbot can produce a rough image.

The specialist market is where category mistakes become expensive. Asking a general chat model to perform high-volume speech transcription, production video creation, semantic search or industrial forecasting can produce a workaround, not a reliable solution. Purpose-built models frequently have clearer success measures and lower operating costs.

A practical procurement method is to group vendors by job: general intelligence, search and retrieval, coding, speech, vision, media generation, safety, hosting and local deployment. Then identify two to five credible candidates per group. That keeps research proportional. A small business does not need to test fifty models; it needs to avoid comparing tools that solve different problems.

The long tail should not be romanticised either. Many models are released with incomplete documentation, weak maintenance commitments, uncertain licences or only self-reported benchmarks. A less-known model earns attention when it offers a verifiable advantage: language support, lower cost, private deployment, better extraction, faster inference or a contract that fits the organisation.

The best directory is therefore not a giant list of names. It is a living vendor map linked to decision criteria. That map can expand when a new model proves relevant and shrink when a provider retires a product, changes terms or fails an evaluation.

Beyond chat with embeddings, rerankers and guard models

The public image of AI remains a chatbot producing paragraphs. Production systems are usually more modular. A customer-support assistant may use an embedding model to search policy documents, a reranker to choose the most relevant passages, a general language model to draft an answer, a guard model to screen content and a rules engine to decide whether a human must approve the response. The language model is only one component in a chain of evidence and control.

Embeddings deserve special attention because they are the foundation of semantic retrieval. Rather than matching only exact words, an embedding system represents the meaning of text in a high-dimensional vector space. This helps a query such as “annual leave carry-over” locate a document that uses “unused vacation entitlement.” It does not guarantee accuracy. Poor chunking, weak metadata, mixed languages, obsolete files or missing permissions can still produce bad results.

Reranking improves precision by comparing the query against candidate documents more deeply than a first-pass vector search. Cohere’s Rerank tools are a well-known example, but many providers offer related capabilities. The retrieval model must be judged on whether it selects the right source, not merely whether it returns something plausible.

Guard models screen prompts and outputs for policy violations, unsafe requests, prompt injection patterns or task-specific risks. Meta’s Llama Guard, IBM Granite Guardian and Qwen3Guard illustrate the category. These models can be deployed before and after a general model, but they need a policy definition. “Safe” is not a universal technical setting; it depends on the users, jurisdiction, domain, permissions and potential harm.

Classifier models, translation models, optical character recognition systems and forecasting models also often outperform general chat models on narrow tasks. A generalist model may be useful as an orchestrator, but a specialist may produce the actual score, transcription or extracted field. Use a general model to reason and communicate; use a specialist when the output has a defined technical target.

This layered approach has a governance advantage. Each component can be tested separately. A retrieval team can measure recall. A safety team can measure block and allow rates. A language-model team can measure answer quality and citation fidelity. A workflow owner can measure escalation accuracy. That is far more defensible than treating an assistant as one mysterious black box.

Vision, audio, video and image models

Multimodal AI is no longer a side feature. Current frontier families increasingly accept images, documents, audio and video, while specialised systems generate or transform media. Google’s model documentation lists separate audio and generative media capabilities; xAI documents dedicated image, video and voice services; Amazon Nova distinguishes understanding, creative and speech categories. The market is moving from text-only prompting to mixed-media workflows.

Vision models can inspect images, charts, screenshots and documents. Their apparent fluency creates a trap: they may describe a chart persuasively while misreading a scale, confuse a logo, omit a footnote or infer information absent from the image. High-stakes visual analysis therefore needs source retention and, where possible, structured extraction or human verification. A visual answer should not be trusted merely because it uses confident natural language.

Audio models cover speech-to-text, text-to-speech, translation and sometimes conversational voice interaction. They should be tested on real accents, background noise, technical terms, names, code-switching and domain language. A transcription system that performs well on clean English audio can fail on a Slovak meeting with English product names, overlapping speakers and poor microphones.

Image generation is changing creative workflows, but it brings rights and brand questions. Teams should define whether generated assets can be used commercially, whether they resemble protected styles or marks, whether metadata is preserved, whether a human reviews claims in images, and whether the model may use customer-uploaded material. A polished visual can create legal, reputational and factual risk faster than a text draft because readers trust images instinctively.

Video generation raises the stakes further. Consistency across frames, person likeness, brand accuracy, disclosure, copyright, consent and misuse prevention all matter. Marketing teams should maintain approval workflows and source records. Newsrooms and public bodies need even stricter provenance controls. A tool that makes plausible footage does not make that footage documentary evidence.

The selection rule is straightforward: match the modality to the evidence and the risk. Use vision models for assisted interpretation, not unreviewed factual certification. Use speech models with domain-specific testing. Use generative media tools with rights, approval and disclosure rules. Multimodal capacity expands what a model can process; it does not remove the need for verification.

Open source, open weights and licences

“Open source AI” is often used loosely. It can mean downloadable model weights, publicly available code, an OSI-approved software licence, open training data, open evaluation data or merely a free API tier. These are not equivalent. Before selecting a so-called open model, identify exactly what is open and what contractual conditions remain.

Open weights allow a user to obtain trained parameters and run them outside the original provider’s servers. That can support private deployment, fine-tuning, research and lower marginal inference costs at scale. It can also create responsibilities for infrastructure, security, abuse prevention, vulnerability management and legal review. Availability of weights does not establish that training data is fully disclosed or that the model can be redistributed without conditions.

Meta’s Llama models demonstrate the distinction. They are widely downloadable and deployable, but usage is governed by Meta’s licence terms. IBM Granite provides selected models under Apache 2.0. DeepSeek released R1 under MIT. These are materially different frameworks, and a commercial team should have legal counsel review the exact model version and intended use before shipping it.

Open-weight models can be cheaper only under certain conditions. A team must calculate GPU or accelerator cost, power, hosting, engineering, monitoring, backup, scaling, security, model updates and support. For occasional use, a hosted API may be cheaper and safer. For high-volume stable workloads with strong infrastructure skills, self-hosting may offer better economics and tighter control.

Open deployment is not automatically private deployment. A model may run inside your cloud account while logs, telemetry, third-party runtimes, vector databases or monitoring systems still create data flows. Privacy depends on the full architecture: storage, identity, network design, vendors, access policies and retention rules.

The most useful question is not “should we use open source?” It is “which level of control do we need, and are we prepared to operate it responsibly?” That framing produces better decisions than treating openness as either a moral virtue or a technical shortcut.

The reality of local models and edge deployment

Local AI means running a model on a laptop, workstation, phone, private server or edge device rather than sending every request to a remote hosted API. The appeal is obvious: lower latency, offline capability, tighter control of data and potential cost savings for repeated workloads. The hidden cost is that local inference turns the customer into part of the AI operator.

Model size is only one constraint. Hardware memory, memory bandwidth, processor type, GPU support, quantisation method, context length, concurrent users and response-time expectations all shape the experience. A model that runs acceptably for one user on a desktop may fail under ten simultaneous requests or collapse when asked to handle a long document.

Quantisation reduces the precision used to store model weights, enabling larger models to fit on limited hardware. It can be highly effective, but not every task degrades equally. A quantised model might preserve casual conversation while losing reliability in structured extraction, multilingual work or code generation. Never assume a community quantisation is operationally equivalent to the original release without testing.

Local deployment also shifts security duties. The organisation must secure endpoints, model files, logs, prompts, vector stores, user access, update channels and tool permissions. A local model with unrestricted access to a device’s files or shell can create a serious risk even if no data leaves the building. Offline does not mean harmless.

Small models have an important place. They can route requests, redact sensitive text, classify documents, generate embeddings, transcribe simple audio, run assistants on devices or act as fallback systems when the network is unavailable. They are often more predictable in cost and latency than frontier cloud models. For narrow, repeatable tasks, a smaller local model may be the smarter engineering choice.

The decision should be grounded in workload economics. Estimate request volume, average prompt length, privacy sensitivity, acceptable latency, uptime requirements, hardware lifecycle and team skills. Then compare hosted and local options over a realistic period. Local models win when control and volume justify operational ownership, not because the word “local” sounds safer.

The three variables that decide most choices

Most model decisions can be organised around three variables: quality, speed and cost. Anthropic’s own selection guidance uses a similar framing, and it is broadly applicable across providers. Quality includes task accuracy, instruction following, factual grounding, format compliance, language ability and error rate. Speed includes first-token latency, total response time, throughput and reliability under load. Cost includes input tokens, output tokens, tools, storage, infrastructure, engineering and review time.

The fourth variable is risk, and it cannot be treated as an afterthought. Risk includes privacy, security, legal exposure, harmful outputs, vendor dependency, model retirement, data residency, content rights and business continuity. A model that is cheap per million tokens may be expensive if its errors require frequent human correction or if its deployment route cannot meet contractual obligations.

Quality should be measured against a task taxonomy. For a support assistant, test intent classification, source retrieval, answer correctness, tone, escalation and compliance. For code generation, test build success, unit tests, security scanning, reviewer effort and regression rate. For document extraction, test field-level accuracy, citations, missing-value handling and performance on messy inputs.

Speed depends on user expectations. A system helping an employee search internal policy can tolerate several seconds if it returns cited evidence. A live voice assistant cannot. A batch classification process may value throughput over first-token latency. Latency targets should be written into the use case before a model is selected.

Cost is often misunderstood because API prices are visible while hidden costs are not. Long prompts, repeated retrieval context, reasoning tokens, tool calls, retries, human review, cloud egress, GPU reservations and support all add up. The cost per successful task is a better metric than cost per token. A stronger model can be cheaper overall if it avoids multiple retries or high manual correction rates.

The most defensible decision uses a scorecard with weighted criteria. Do not give every criterion equal weight. A legal department may place data controls above speed. A consumer app may prioritise latency and unit economics. A research team may accept high cost for the strongest reasoning. The optimal model is an expression of priorities, not a universal fact.

Benchmarks explain less than their headlines imply

Benchmark results are useful, but they are easy to misuse. A benchmark may test mathematics, code, multilingual knowledge, visual reasoning, safety, instruction following or long-context recall. Strong performance on one says little about another. A model can score highly on an academic test and still fail to follow a company’s JSON schema, misclassify a support request or invent references in a research summary.

Stanford’s 2026 AI Index reports rapid benchmark gains, including large improvements on coding and hard reasoning evaluations. It also warns indirectly through its data that benchmark saturation is accelerating: tests designed to remain difficult can become less discriminating within months. A benchmark is a signal of possible capability, not proof of fit for a production workflow.

Provider benchmarks deserve special care. They may use favourable prompting, selected tasks, internal infrastructure or comparison baselines that do not match the buyer’s environment. That does not make them useless. It means they should generate hypotheses for testing: perhaps this model is worth trying for coding, multilingual extraction or image understanding. They should not close a procurement decision.

Safety benchmarks have similar limits. MLCommons’ AILuminate work provides structured testing across hazard categories, but a safety score is not a guarantee that a specific application is safe. Risk depends on the system prompt, tools, user population, deployment domain, monitoring and escalation process.

Benchmark leakage is another concern. When test questions become public and valuable, models may be trained on similar material or optimised toward the metric. That can make a score look better than practical ability. A private evaluation set drawn from your own historical tasks is harder to game and more relevant.

The best benchmark is a controlled trial using your own representative workload. It should contain easy, typical and difficult cases; current and stale documents; ambiguous instructions; multilingual samples; malformed inputs; harmful requests; requests that should be refused; and tasks where the correct outcome is to ask for human help. That is harder work than reading a leaderboard, but it is the difference between evidence and marketing.

Context windows do not equal understanding

Context window size refers to how much input a model can consider in one request. Modern models may advertise very large windows, sometimes large enough for lengthy books, codebases or video transcripts. That is useful, but a large context window is not a promise that every detail will be understood, retained, weighed correctly or cited accurately.

As context grows, several failure modes become more likely. The model may pay too much attention to the beginning or end of a long prompt, lose a critical clause in the middle, follow conflicting instructions, overvalue irrelevant material or produce a plausible synthesis that blends separate documents. Long context can also increase cost and latency substantially.

The right use of long context is selective. It is valuable for reviewing a contract bundle, analysing a repository, summarising a meeting archive, comparing policy versions or processing a long report. It is not an excuse to paste every corporate document into a prompt and hope the model will discover the relevant answer. Retrieval, document structure and explicit evidence requirements remain necessary.

Long-context evaluation needs specially designed tests. Place key facts at different positions. Include conflicting versions. Add irrelevant but similar documents. Test whether the model quotes the right page, flags uncertainty and notices that a document is out of date. Ask it to return a source map rather than only a narrative answer.

Context length also interacts with privacy. Large prompts can contain more personal data, confidential commercial information and copyrighted material. A team should define what may enter the model, how it is stored, who can access it and whether the provider uses it for service improvement or training under the selected terms. The ability to ingest an entire archive does not create permission to do so.

The practical rule is simple: use the smallest evidence set that can answer the question reliably. Build retrieval and filtering first, then use long context where it adds genuine value. That approach improves cost, speed, explainability and accuracy at the same time.

RAG beats gigantic prompts for organisational knowledge

Retrieval-augmented generation, usually called RAG, combines a model with a search process that retrieves relevant source material before the model answers. It is one of the most useful patterns for organisational knowledge because it allows answers to be grounded in current, authorised documents rather than relying on the model’s training data. RAG is not a feature toggle; it is an information architecture.

A good RAG system needs clean source documents, ownership, version control, metadata, permissions, chunking, embeddings, retrieval, reranking, citation design and evaluation. Weakness at any step can degrade the final answer. A polished response with citations may still be wrong if the system indexed an outdated policy or retrieved a similarly named but irrelevant document.

Embeddings and rerankers are central. Google documents Gemini Embedding for semantic search and retrieval, while Cohere explains that Rerank models order documents by relevance to a query. These tools help move a RAG system from keyword search toward evidence selection.

The most important RAG question is whether the answer is grounded in the right source at the right time. Evaluation should therefore include retrieval recall, ranking precision, citation correctness, answer completeness, abstention behaviour and access-control compliance. It should also test direct and indirect prompt injection in documents, such as hidden text instructing the model to ignore policy or reveal secrets.

RAG is often better than fine-tuning for changing knowledge. A company handbook, product catalogue or regulatory rule changes more often than the model should be retrained. Updating the indexed source and re-evaluating retrieval is usually faster, more transparent and easier to audit. Fine-tuning may still help with stable output style or narrow classification behaviour, but it is not a replacement for current sources.

The user interface matters. A system should show citations or links in a way a human can inspect. It should distinguish a sourced answer from an inference, state when no reliable source was found and offer escalation where required. The strongest RAG systems make it easy to verify the answer, not merely easy to read it.

Coding models, tool use and agent workflows

Coding AI has moved beyond autocomplete. Modern systems can read repositories, propose multi-file changes, write tests, run commands, inspect errors, call APIs and iterate. GitHub Copilot, OpenAI coding workflows, Qwen Code, Grok Build and related tools represent a shift from “suggest a line” to “perform a development task.” That makes them more useful and more dangerous.

The core capability is tool use. A model can request a function call, run a test suite, query a database, search documentation or trigger a workflow. The system then supplies the result and the model continues. This resembles an agent, but the intelligence lies in the combination of model, tools, permissions and loop design. An agent with broad credentials is a software system with an unusually persuasive interface, not a harmless chatbot.

Coding evaluations should begin with repository-level tasks rather than toy snippets. Test whether the assistant reads existing conventions, changes the minimum necessary files, writes useful tests, handles errors, respects security policies, avoids leaking secrets and explains uncertainty. Include tasks where the correct response is to ask a question rather than guess an architecture.

Human review remains essential. A code assistant may produce syntactically valid changes that introduce a race condition, security weakness, performance regression or licensing concern. The measure of success is not lines generated. It is the net effect on delivery speed, reliability, review time and defect rate.

Permission design is the decisive control. Start with read-only access. Limit tool scopes. Require approval before writing files, running destructive commands, deploying code, sending messages or accessing production data. Log tool calls. Use sandbox environments. Keep credentials short-lived and isolated. Never assume that a model’s refusal behaviour is sufficient access control.

Agent workflows should also have stop conditions. Endless retries can waste money and create unintended changes. Define maximum steps, time budgets, token budgets and escalation rules. A reliable agent knows when it has not succeeded. That behaviour needs to be designed and tested, not assumed from a model’s marketing description.

Privacy, retention and data residency before the prompt

Privacy review should happen before a team uploads documents, connects a data source or enables an agent. The central questions are practical: what data enters the system, where it travels, how long it is retained, who can access it, whether it is used for training or service improvement, and how deletion or legal holds work. A model’s answer quality does not compensate for an unacceptable data flow.

Consumer and enterprise tiers can differ materially. Direct provider APIs, cloud-platform deployments and workplace products may have separate terms, logging defaults, regional availability and administration controls. A company should not infer enterprise safeguards from a free consumer account, nor assume that an enterprise subscription automatically makes every connected workflow compliant.

Data residency is more than selecting a European region. It involves inference location, backups, telemetry, content filtering services, support access, subprocessors, model-hosting route, logging and vector database location. A deployment may satisfy one residency requirement while failing another. Legal and security teams should review the actual architecture and contract documents.

Minimise data before it reaches the model. Remove unnecessary personal data, redact secrets, apply access controls, use retrieval filters, avoid sending entire mailboxes or drives, and establish retention periods. For sensitive tasks, consider whether a smaller local model or a private cloud deployment can meet the need with less exposure.

Prompt injection deserves special attention. A malicious document, webpage or email can include instructions aimed at the model rather than the user. If an agent can access tools, such instructions may try to exfiltrate data or change workflow behaviour. Defences include separating trusted instructions from untrusted content, constraining tools, validating outputs, limiting permissions and testing adversarial documents.

NIST’s Generative AI Profile identifies risks including confabulation, data privacy, information security, intellectual property and value-chain integration. Those categories are useful because they force teams to assess the whole system rather than the model alone.

The European compliance layer

For organisations operating in the European Union, model selection increasingly intersects with the EU AI Act, GDPR, sector rules, contract obligations and internal governance. The AI Act distinguishes between AI systems and general-purpose AI models. European Commission guidance states that obligations for general-purpose AI models apply to the model itself, while obligations for AI systems depend on the context of use.

The important practical point is that buying a well-known model does not decide compliance. A company deploying an AI system must consider its own role, use case, users, data, impact and control mechanisms. An internal summarisation tool differs from an AI system used in recruitment, credit decisions, education, public services or other high-risk contexts. The use case can create obligations that the model name does not reveal.

General-purpose model providers face documentation, information-sharing and copyright-related obligations under the AI Act framework, with additional duties for models classified as presenting systemic risk. Downstream deployers should not assume the provider’s compliance work transfers automatically to their own product. They need sufficient documentation, contract terms, assessment records and governance procedures for their specific implementation.

For a buyer, the procurement checklist should cover provider documentation, model card or technical information, known limitations, safety measures, copyright policy, data-processing terms, region, audit support, incident reporting, change notifications and the ability to exit or migrate. Compliance evidence should be requested before production launch, not after a regulator or customer asks for it.

The AI Act should not be treated as a reason to avoid AI entirely. It is a reason to classify uses, document decisions, control risks and avoid deploying systems with unclear purpose or accountability. A disciplined evaluation process is useful even where a particular application sits outside high-risk categories because it improves quality, security and business continuity.

The safest organisational pattern is cross-functional: product owners define the value and user need; technical teams assess capability and architecture; legal teams examine contracts and rules; security teams assess access and threat models; risk owners define escalation and monitoring. No single team can make a defensible AI model decision alone.

A testing programme that produces defensible choices

A defensible model choice comes from a repeatable test programme, not a charismatic demo. Start by defining the job in one sentence: “Answer employee policy questions with citations,” “Extract invoice fields from scanned PDFs,” “Draft unit tests for a TypeScript service,” or “Classify incoming support tickets.” Then define the acceptable failure rate, required speed, expected volume, data sensitivity and human review point.

Build a test set from real work. Include straightforward examples, difficult cases, ambiguous requests, outdated sources, conflicting instructions, multilingual content and samples that should be rejected or escalated. Keep a protected holdout set that is not used to improve prompts. The test set should reflect the errors your organisation cannot afford.

Measure results quantitatively where possible, but retain human review. Accuracy can be field-level extraction accuracy, correctly cited answer rate, test-suite pass rate, retrieval recall or classification precision. Human reviewers should also score usefulness, clarity, tone, safety, uncertainty handling and whether the model took an appropriate action rather than merely producing attractive prose.

A compact model-selection scorecard

The scorecard should be weighted by use case. A public customer assistant may place response speed and tone near the top. A compliance workflow may weight citation accuracy, privacy and human escalation far more heavily. A model that wins an unweighted average can still be the wrong choice.

Run a pilot with real users but limited permissions. Monitor errors, cost, latency, user trust, escalation volume and unexpected behaviour. Compare the system against the current non-AI process, not only against other models. The relevant question is whether it creates measurable improvement without unacceptable risk.

Finally, document the decision and schedule reassessment. Models change, prices move, licences shift and new versions arrive. A six- or twelve-month review cycle may be appropriate for stable work, while fast-moving customer products may need much more frequent evaluation. Model governance is a lifecycle discipline, not a procurement form.

A practical shortlist for individual users and small teams

Individuals and small teams usually do not need a giant model catalogue. They need a shortlist that reflects their work. For general writing, brainstorming, research assistance and file-based analysis, start by comparing the major consumer and API ecosystems: ChatGPT, Claude and Gemini. Add Grok or another provider only when its current features, style or price clearly match the task. Test the work you actually do for a week rather than trusting one viral comparison.

For software development, compare GitHub Copilot, direct coding agents and model-backed terminal tools on a real repository. Measure test pass rate, quality of explanations, speed of review and whether the tool respects your standards. Do not give it production credentials in the first experiment. Start with a sandbox branch and a well-defined task.

For private notes, local writing, offline use or experimentation, explore open-weight models through reputable runtimes and model hubs. Llama, Qwen, Mistral, Granite and DeepSeek-related releases may be relevant, but choose based on hardware and licence. A small model that runs reliably on your device may be more useful than a giant one that technically starts but responds too slowly to use.

For internal document search, begin with retrieval rather than a general chatbot. Use a controlled document set, embeddings, reranking, citations and clear permissions. A hosted model can write the answer, but the system’s quality will depend heavily on how well it finds the source. Do not promise a “company ChatGPT” until you have tested retrieval, access controls and stale-document handling.

For creative work, use the specialist category. Image, audio and video tools should be chosen on output rights, brand suitability, workflow speed and consistency. A general language model may help write a brief, but it is not necessarily the right production tool for the visual asset itself.

Small teams should maintain a simple model register: approved tools, prohibited data, business owner, allowed use cases, pricing owner, data settings, review dates and escalation contact. That level of discipline is manageable and prevents the chaotic spread of untracked AI accounts, unapproved uploads and unsupported workflows.

A durable way to keep the map current

The AI model market will not become simpler. New names will appear, model families will merge, versions will retire and applications will conceal more routing behind friendly interfaces. The answer is not to memorise every model. The answer is to maintain a decision framework that survives model churn.

Track providers in categories rather than as a flat list. Keep a frontier generalist shortlist, an open-weight shortlist, a retrieval shortlist, a coding shortlist, a media shortlist and a local-deployment shortlist. Review each only when a relevant release, contract change, price movement or new requirement occurs. This is far more manageable than chasing every announcement.

Subscribe to official release notes for the models already in use. Monitor deprecation pages, migration guidance, pricing changes and platform notices. Keep model identifiers in configuration rather than burying them across code. Build a fallback route for important applications. The first time you learn that a model is retiring should not be when production traffic fails.

Maintain an internal evaluation corpus and update it with real failures. Every incorrect answer, poor retrieval, unsafe suggestion, broken format or tool misuse is useful test data once it has been reviewed and anonymised where necessary. Over time, the organisation develops its own model intelligence rather than depending entirely on public benchmarks.

Be sceptical of absolute claims. “Best model,” “fully private,” “hallucination-free,” “open source,” “human-level,” “agentic” and “enterprise-ready” are not decisions; they are prompts for further questions. Ask for the version, task, region, contract, evidence, latency, price and limitations. Precision is the habit that makes an AI model market understandable.

The final lesson is less exciting than a leaderboard but more useful: select a model as you would select any critical component. Define the job, identify risks, compare credible options, test on real work, document the result, control permissions and reassess when the environment changes. That is how ChatGPT, Claude, Copilot, Gemini, Qwen, Llama, DeepSeek and the many less famous models become manageable choices rather than an endless stream of names.

Questions readers ask before choosing an AI model

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

OpenAI API
Official overview of OpenAI’s API platform and frontier model capabilities.

Models overview
Anthropic’s official guide to the Claude model family.

Choosing the right model
Anthropic guidance on balancing capability, speed and cost.

Model deprecations
Anthropic documentation on model retirement and migration considerations.

Gemini API models
Google’s current documentation for Gemini, audio and generative media model families.

Gemini Embedding
Google documentation for semantic search, retrieval and recommendation embeddings.

Microsoft Foundry Models overview
Microsoft documentation on its multi-provider model catalogue.

GitHub Copilot AI models
Microsoft documentation describing model selection and custom model support in a Copilot environment.

xAI models
xAI’s official current model selection guide for Grok, coding and media capabilities.

Amazon Bedrock models at a glance
AWS overview of Bedrock-supported foundation models.

What is Amazon Nova
AWS documentation on Amazon Nova understanding, creative and speech model categories.

Llama downloads
Official Llama model download and availability page.

The Llama 4 herd
Meta announcement covering Llama 4 Scout and Maverick.

Mistral Models overview
Mistral’s official model catalogue and capability overview.

Mistral model selection guide
Mistral guidance on comparing price, performance, features, context and licensing.

Qwen3
Official Qwen release information for the Qwen3 family.

DeepSeek API documentation
Official DeepSeek API documentation, model naming and compatibility information.

DeepSeek R1 release
DeepSeek’s official R1 release announcement and licence information.

Cohere models
Cohere overview of Command, Embed and Rerank model roles.

Cohere Rerank
Official explanation of semantic reranking for search and retrieval.

IBM Granite 4.0
IBM documentation on Granite language-model architecture and deployment roles.

Granite Guardian
IBM documentation for safety-oriented Granite Guardian models.

NIST AI 600-1 Generative AI Profile
NIST risk-management guidance for generative AI systems.

General-purpose AI models in the AI Act
European Commission explanation of AI Act obligations for general-purpose AI models.

Guidelines on the scope of obligations for GPAI providers
European Commission guidance on the scope of general-purpose AI model obligations.

The 2026 AI Index Report
Stanford HAI report on capability, benchmarks, adoption and AI market trends.

AILuminate LLM v1.1
MLCommons release covering safety-benchmark development for language-model systems.