What Makes an AI System Specific to Your Business?

💡 TL;DR: Key Takeaways

• Making AI specific to your business does not mean teaching the model everything about the company. Current information should come from authoritative systems, explicit rules should remain in software, and permissions should be enforced by identity and access controls.
• The system around the model can turn the same model into a very different business capability. Data, tools, workflow, approvals, and measurement account for much of that difference.
• Some workloads do justify a specialist model. The decision should follow from a pattern the model must learn and a measured performance gap—not from a vague desire to make the AI “ours.”

Imagine a procurement team comparing proposals from three suppliers. They upload the files to a language model and ask it to compare prices, delivery dates, and warranty terms. The model produces a clean table and recommends one supplier.

That may be useful document analysis. It does not show that the system has made the right purchasing decision for this company.

Is the recommended supplier approved? Is the same item already in stock? Does an existing contract offer a better price? Is the requester allowed to spend that amount? Which approvals must occur before a purchase order can be created?

The proposals do not contain those answers. Some live in current company records, some in business rules, and others in the authorization system. The model can understand the proposals. The business capability only appears when the rest of the system works with it.

Company knowledge is not the same as a company-specific system

When people talk about “company-specific AI,” they often mean a model trained on company data. That can be useful for some workloads, but not every company-specific requirement belongs inside the model.

Product catalogues, procedures, and contracts can be supplied directly or retrieved when needed. Stock levels, order status, and balances should be read from the relevant API or database. Spending limits and approval sequences belong in software. The access-control system decides which records a user may see.

In the article on fine-tuning, I separated information, explicit rules, and patterns that must be learned from examples. The system-level consequence is simple: requirements that are specific to your company do not all live in model weights.

This map helps place each requirement where it can be maintained and controlled:

A model may use several of these components, but it does not become their owner. Reading a stock record does not make the model the source of truth for inventory. Explaining a spending limit does not give it authority to place an order.

The same model can support two very different systems

Researchers at Berkeley AI Research use the term compound AI system for systems that combine model calls with retrieval, software tools, and other components. The label matters less than the distinction: the result comes from the components working together, not from the model alone.

Microsoft's current guidance for AI application design draws similar boundaries between model inference, knowledge sources, orchestration, tools, and the client layer. It also recommends enforcing user permissions in the knowledge layer and giving tools their own security controls.

The same model can therefore serve as a proposal summarizer in one company. In another, it can be part of a larger system that reads current inventory, compares contract terms, and prepares a purchase request.

The difference is not merely the instruction sent to the model. It is which source the company treats as authoritative, which action can run under which identity, which exception goes to a person, and where the final result is verified.

Do stronger general-purpose models remove the need for this architecture?

There is a serious counterargument here. If general-purpose models can handle more work each year, do companies still need so many separate components?

It is becoming possible to process text, images, and audio with one model, supply long documents directly, and let the model call software tools. Some pipelines that once required several specialist models can genuinely become simpler.

In its Gemini 2.5 technical report, published in 2025, Google DeepMind described a model family that combined text, image, and audio inputs with long context, reasoning, and tool use. Developments like these can absorb work that previously required a chain of separate models.

Model capability and system responsibility are still different things. Even if a model could read a million-row product catalogue, it would not independently know which price is valid today, whether this user may see a particular contract, or whether the purchase order was actually created. Those are questions of current state, authority, and completed action.

As general models improve, some specialist components will disappear. The company's sources, rules, and responsibilities will not turn into model capabilities.

Some patterns genuinely need to be learned

Not everything that makes a system company-specific belongs in the surrounding software. The reverse is also true: adding a few documents or connecting an API will not solve every problem.

A company may need to sort thousands of daily requests into its own stable categories. If a general model keeps making the same mistakes on real messages, a smaller model adapted with labelled examples may be more accurate, faster, or cheaper.

A 2025 EMNLP study on text classification asked how many labelled examples a small task-specific model would need to compete with a large general-purpose model.

Across eight tasks, the researchers found that specialist models could, on average, match or beat the general models with roughly one hundred labelled examples. Some tasks required substantially more data.

If your company repeatedly assigns similar requests to the same fixed categories and has correctly labelled examples, a small model trained only for that job may be worth testing. One hundred examples is not a universal threshold; the requirement changes with the task and the data. The practical finding is that the largest general-purpose model is not automatically the best choice for narrow, repetitive work.

Here, the model has a clearly defined job. When the answer is not written in a document, cannot be calculated by an explicit rule, and depends on a relationship hidden in historical examples, model specialization may be justified. It still has to prove itself on the real workload.

The business capability should survive a model change

The more company knowledge, rules, and permissions are buried in uncontrolled model behaviour, the harder the system becomes to understand and change. A new model may interpret the same instructions differently. The team may not know which examples or hidden assumptions made the old behaviour work.

Keeping information sources, business rules, tool contracts, access boundaries, and evaluation examples separate makes a model change easier to test. A replacement model can be evaluated with the same sources, permissions, and representative work.

This does not make the model unimportant or effortless to replace. Model choice directly affects quality, cost, speed, and the work the system can perform. It does mean that the entire business capability does not have to depend on one provider's model behaviour.

Return to the procurement example. The model can read the proposals and explain the differences. The company system retrieves the correct stock record, opens the contract according to the user's permissions, applies the spending rule, requests the right approval, and verifies the resulting order in the system of record.

Sometimes a fine-tuned or specialist model is what makes an AI system specific to the company. More often, the distinction comes from the system that determines which information the model can use, which tools it can call, what authority it has, and which business result it must produce.

So “How do we customize the model for our company?” needs two companion questions: What does the model genuinely need to learn? What must the system supply, constrain, and verify?

The previous article explains when requests should be routed across multiple AI models.

You can find the other decisions about models, information, authority, and evaluation in the guide to designing an AI system for your business.