How to choose an AI model for your company: OpenAI, Claude or Gemini? A comparison and a test on your own data

In many companies the choice of model is made indirectly. A company working on Microsoft 365 gives its employees Microsoft Copilot and uses the models Microsoft has chosen. A company on Google Workspace uses Gemini built into its email and documents.

A deliberate choice of model is needed in the three situations described below. If none of them applies to you, a good rollout of the tool you already have matters more than the model.

Each of the three providers offers models in several variants: the most powerful and most expensive, a balanced one, and a fast, cheap one. Specific version numbers change every few months, so the table gives family names rather than versions.

For a Polish company, the last column is important. The same models may process data inside or outside the EU, depending on which service you use them through and how it is configured. The table describes the position as of October 2026.

Before you compare the quality of answers, decide what matters to you. Different features count for an employee assistant, for reading foreign invoices in bulk and for analysing contracts.

One term is worth knowing: the context window. This is the amount of text a model can take into account at once, e.g. a whole contract with its appendices. All three families now have windows large enough for typical business documents, but differences appear with very long sets of documents.

When you use a model through an API, you pay for tokens, which are pieces of text, roughly fragments of words. Text sent to the model and the text the model sends back are counted separately. The response is usually several times more expensive per token.

The differences between variants within one family are large. In Anthropic’s October 2026 price list, the most powerful Claude (Fable) costs USD 10 per million input tokens and USD 50 per million output tokens. Opus, which Anthropic recommends for most tasks, costs USD 4 and USD 20. The smallest, Haiku, costs USD 0.10 and USD 0.50 respectively for shorter requests.

An example: a company processes 2,000 documents a month. Assume each is about 3,000 tokens and the model’s response is about 500 tokens. That gives 6 million input tokens and 1 million output tokens a month.

The most powerful model would then cost 6 × 10 + 1 × 50 = USD 110 a month, and Opus 6 × 4 + 1 × 20 = USD 44. The smallest would cost 6 × 0.10 + 1 × 0.50 = USD 1.10. At this scale, the cost of the model is small compared with the cost of the rollout and people’s time. The difference starts to matter with hundreds of thousands of documents, or with agents that query the model many times for each case.

Public model rankings show results on tasks prepared by someone else. They will not tell you how a model will handle your contracts, your industry terminology and your exceptions. That is why it is worth basing the decision on your own test.

Testing two or three models on one process usually takes a few weeks, most of it spent preparing examples and assessing the results. We describe the steps below.

The table below shows where to start in the most common situations in a mid-sized company. It is a starting point for a test, not a final recommendation. For particularly sensitive data, such as medical data, also consider a model running on your own servers, although it is more expensive to maintain.

For most mid-sized companies, one main provider is simplest. It simplifies contracts, cost control, training and security rules. It is worth adding a second model when a test shows a clear advantage for a specific task, or when bulk tasks can be given to a cheaper variant.

Whatever the number of models, design your solution so that the model can be swapped without rebuilding the process. Cloud services that offer models from several providers under a single contract help with this. Examples are Microsoft Foundry with OpenAI and Claude models, and Amazon Bedrock with Claude and OpenAI models.

With several models, you need clear rules: which process uses which model, who tests new versions and who approves a change. Without them, each department chooses its own way, and costs and risks are hard to control.

These mistakes usually come from haste or from trusting a single presentation. Each of them can be avoided with the test described above.