Examples of AI Implementation in Business by Industry

AI in business handles specific operations: recognizing text and images, classifying tickets, preparing documents, and calling tools according to procedures. A single process may combine computer vision, OCR, a language model, and standard software checks.

Below are KT.Team case studies by industry, with the outcome and project stage indicated.

A working service, a demonstration using historical data, and a future implementation program provide different types of evidence.

Assessing your project requires a comparable task, data, and the cost of checking the result.

For a manufacturing company, accounting and document processing can be a separate area for AI application.

Their results should be measured separately from equipment performance, product quality, and production lead times. OSNO-VA - AI accountant - a KT.Team product for accounting operations in 1C and related systems. The published case describes API/MCP access, rule-based execution, action auditing, and escalation of exceptions to an accountant.

Round-the-clock processing of standard operations is a product mode, not a measured availability percentage.

The case does not specify the measurement period, the volume of processed operations, or a proven reduction in production costs.

For the pilot, document accuracy, the exception rate, and the accountant's time spent reviewing exceptions are checked here.

In iCdocs case study A logistics company handled thousands of shipments and multipage document packages every day. KT.Team developed a Python-based system that converts scans to text, identifies document types and pages, and groups documents by order number, trip, or counterparty.

Recognition here means OCR and computer vision; sorting, compilation, and storage also use software rules.

The use of an LLM is not stated in the published case.

An operator can verify recognized values and flag incorrect fields, while the change history is stored in the system.

The case reports an early recognition result of around 80%, but does not disclose the test sample or measurement period; this must not be presented as the final accuracy of a production system.

For a new pilot, it is more useful to measure in advance missing required documents, field errors, and the operator's time to correct a document package.

In LLM ticket classification case study For one of CIS's top three developers, KT.Team prepared a demonstration environment using a dataset of 12,000 resolved tickets in the first quarter.

The year of the quarter is not specified in the published text.

Before the demonstration, the data was cleaned of empty descriptions, email chains, and unusable labels.

The model first identifies the team, then the service within that team.

Instructions are refined based on errors, and test requests are checked for regression.

The case demonstrates an approach and methodology for further implementation; 12,000 requests indicate the size of the source dataset, not the number of successfully served customers or an accuracy rate.

An industrial pilot requires specialist review, metrics for each category, and rules for escalating ambiguous tickets.

Related design scheduling system It combines scheduling, data migration, and integrations. LLM/script-based classification is mentioned for a separate integration area with Naumen.

This does not justify attributing all scheduling and planning functions to AI or promising a percentage reduction in construction costs.

In the OSNO-VA financial agent case KT.Team separated the data, tool access, and calculation logic.

Data is stored in a database, the agent receives it through MCP, and calculation rules are executed in skills and scripts.

The language model uses verifiable tools; the numerical result must be reproducible according to the specified rules.

The published case confirms the structure of the financial system.

The calculation volume, observation period, and share of answers requiring no corrections are not provided.

When replicating the approach, validate the result against reference calculations, access to financial data, and handling of missing input values.

A designated specialist is responsible for resolving discrepancies.