AI Assistant for Wholesale Distribution: Automating Document Search and 1C Integration

What is an internal AI assistant: architecture overview for wholesale trading

An internal AI assistant is not a ready-made chatbot from the cloud. It is an architecture that unifies a self-hosted agent framework, a language model running on Russian infrastructure, semantic search over your own knowledge base, and integrations with 1C, Bitrix24, and other business systems. When a sales, logistics, or purchasing team member asks a question in natural language through a messenger, web interface, or internal chat, they receive an answer grounded in real data from your accounting systems and document archive.

The process works like this. An employee types a request like 'Show me the balance of product X for counterparty Y' or 'Help me prepare a commercial proposal based on our latest template'. The framework receives the text, passes it to the language model, which determines the intent and which integrations are needed. The assistant calls the 1C API or triggers document search, collects the results, and presents an answer. If the request is to draft a document, the assistant prepares a preliminary version that the employee reviews and sends forward. If it is a command to create a task, the assistant automatically enters it into Bitrix24.

One critical point: many ready-made agent frameworks are configured by default to send requests through OpenRouter or to OpenAI and Anthropic clouds outside Russia. If you take an off-the-shelf framework without reconfiguring it, sensitive data will leak abroad. When setting up, we explicitly redirect all components to local and Russian endpoints, and this is verified during the initial security audit.

Customs declarations, counterparty details, employee personal data, and cargo information contain confidential information that by Russian law (152-FZ) must not be sent to OpenAI or Anthropic clouds overseas. In this architecture, all components remain in Russia. The model runs through Yandex AI Studio (Russian hosting), the framework and document database are on the client's server, and integrations with 1C are also protected. The endpoint is fixed to the Russian perimeter, and no sensitive data leaves the country.

Answer quality depends directly on the quality of your company's knowledge base. If documents are poorly structured or outdated, RAG will return noise. Implementation is not a one-time project but a gradual process: document corpus preparation, configuration, pilot with one department, then expansion. There are scenarios where an internal assistant is simply overkill, for instance if the team is small and resolves everything through direct conversation.

RAG and search over your internal document library: how it works

RAG stands for retrieval-augmented generation. The concept is straightforward: before answering, the system first searches for relevant documents from the client's library, then passes them to the language model, which generates an answer based on real internal data, not training datasets. In wholesale trading, this means an employee can ask a natural-language question about delivery terms, customs procedures, standard contracts, and receive an answer from actual company documents instead of the internet.

Indexing works this way. Documents are split into chunks (typically 1-5 paragraphs), converted to vector representations, and stored in a vector database. This happens once during corpus preparation, then again when new documents are added.

When a user asks a question, the agent converts it to a vector, searches for semantically similar chunks from the base (usually the top 3-5), and passes them along with the question to the language model.

The model then generates an answer based on the retrieved documents. If a document does not exist in the base, the model cannot invent it. If a document is outdated, that becomes immediately apparent.

The tangible benefits are significant. Your employees get information from THEIR documents, not from the internet or generalized training data. When delivery terms change, you update one document, and all future answers reflect that change. Documents remain on the company server and never leave for OpenAI or other cloud services. Questions can be answered in a user-friendly way even though the underlying data is highly structured.

Common use cases show the practical value. An employee can ask 'What documents do we need for customs clearance in Germany?' and the system retrieves all relevant checklists and procedures. Or 'Show me our standard dealer contract', and the template is pulled directly. Or 'What is the procedure for handling quality complaints?' and the system locates the regulations and escalation chain.

RAG does have real limits. If your documentation is poorly organized, contains contradictions, or mixes old and current versions, answers will be misleading. That is why RAG implementation always starts with preparation: audit the corpus, remove duplicates, version documents, add metadata (date, responsible department, freshness status). Answer quality is directly proportional to knowledge-base quality and organization.

Structuring and preparing your knowledge base takes time, but it is the foundation of a good system. If you launch RAG hastily on a dirty base, results will be poor. This is not an instant solution but rather the foundation for a good one.

The technical stack combines a self-hosted agent framework (open-source, no ChatGPT dependency), a vector database (Qdrant or Milvus), and a language model from Yandex AI Studio. The framework and vector database run on the client's server. Data never crosses the border. For 152-FZ compliance, this is essential. Many agent frameworks route through OpenRouter or OpenAI by default, creating a data-leak risk. You must explicitly configure them to work only with internal services.

Integration with 1C: accessing counterparty data, products, orders, and inventory

Instead of learning the 1C interface or calling accounting, an employee can simply ask the assistant in chat. What is the balance of product A2043 at the Moscow warehouse? Which orders are overdue for counterparty XYZ? The system connects through the 1C REST API using function-calling, pulls data from the dictionaries, and returns an answer in natural language.

The process follows this pattern. A user writes a request. The language model parses the intent and determines which data is needed (for example, GetProductBalance or ListOrdersByCounterparty functions), passes the required parameters, retrieves results from 1C, and translates them into a human-readable response. Previous requests remain in the assistant's context, so it can clarify details or develop the topic without re-querying the database.

Integration covers the core 1C dictionaries. These include counterparties with tax IDs, bank details, and creditworthiness ratings. Products with article numbers, balances by warehouse, purchase and sale prices. Orders and invoices with statuses, dates, amounts, and line items. Accounts payable, advances, and payment terms. If 1C is linked to a CRM, the history of communications with each client is available.

The implementation includes counterparty lookups with tax ID, status, creditworthiness rating, and assigned managers. Product queries by warehouse balance in units and revalued cost. Order and invoice history with status, dates, positions, and responsible parties. Settlement data covering debts, advances, and payment terms. Communication history if 1C is connected to a CRM system.

There are real risks to manage. Language models can misinterpret a complex request or invent a function parameter, a phenomenon called hallucination. For critical operations like payment approval, shipment confirmation, or customs declaration filing, human verification is mandatory. If 1C has dirty data (duplicate counterparties, typos in article numbers, stale balances), results will be inaccurate. Integration requires upfront 1C API configuration, function testing, and documentation of business logic.

All requests are logged. The system does not send information to OpenAI or other overseas cloud services. The language model runs through Yandex AI Studio (Russian hosting), the framework is deployed on the company server, and logs never leave the local network.

Preparing documents: drafts for customs declarations, commercial proposals, and performance certificates

Preparing commercial proposals, performance certificates, and customs declarations is routine work that consumes time. Each document must correctly state counterparty data, product details, amounts, and terms. An error in a declaration can cause customs delays. A typo in a proposal damages professionalism.

The assistant helps reduce manual data entry and minimize errors. It pulls from two sources: templates and patterns accumulated in the company's internal document library, and current data about counterparties, products, and orders in 1C. On request, for example 'Draft a proposal for LLC Logistics Plus for a shipment batch', the assistant performs several steps in sequence.

First, it finds the counterparty's details in 1C, delivery conditions, and history of previously issued orders. Second, it selects from the internal library similar examples of proposals with correct structure and style. Third, it assembles a draft based on the data and templates. Fourth, it fills in current amounts, terms, payment conditions from the product catalog.

Technically this works through RAG. The assistant searches the base for similar proposal, certificate, and declaration examples, extracts structure and formatting logic from them, then applies that logic to new data. If a price or balance changes in 1C, the document gets current numbers. The entire process from request to finished draft takes 20-40 seconds depending on document size.

Language models can make mistakes. Numerical values in draft documents require human verification before sending to customs or clients. This is not an automated submission system but an assistant for draft preparation. Customs declarations and counterparty details are personal data under Russian law and must not leave for OpenAI or Anthropic servers. The framework runs self-hosted on the client's server with the language model connected through Yandex AI Studio.

The assistant is a co-author of a draft, not a replacement for an accountant or customs officer. A document always goes to a person for review before sending. If your company's internal document base is well-structured and regularly updated, draft quality will be high. If not, the assistant may introduce errors. This demands a thoughtful approach to knowledge-base preparation and maintenance, but the payoff is significant when the volume of routine work runs into hundreds of documents monthly.

Task automation in Bitrix24: creating tasks and recording them in the tracker

Creating tasks in a tracker is a routine operation. An employee writes the task text, selects an assignee, sets priority and deadline, attaches documents. The assistant can take this burden through Bitrix24 API integration.

The flow is straightforward. An employee describes a task in plain language: 'Create a task for Ivan to review the proposal from LLC Horns and Hooves, due end of week, high priority'. The assistant parses the natural-language text, extracts assignee, topic, priority, and deadline. It sends a request to the Bitrix24 API (tasks.task.add) and the task appears in the tracker with the correct assignee, description, and date.

Bitrix24 integration in the agent context is more than a webhook. It includes finding the right employee by name or role (the assistant is trained on the company directory), mapping priority and status, linking to a project or group.

The benefits are concrete. No need to manually fill a task form. All tasks are created in a consistent format. Requests are created in seconds, no need to remember the exact tracker format. Every task is logged, showing who requested creation and when.

Real-world constraints exist. A language model may misidentify an assignee if multiple people share a name or the name is stated imprecisely. The assistant should either ask for clarification (There is Ivan Petrov and Ivan Smirnov, which one do you mean?) or create the task with a presumed assignee but require confirmation from a manager before fixing it.

Deadlines are often stated relatively, like 'end of week' or 'by tomorrow noon'. Precision is required here. The assistant must convert it to a specific date and output a verification message: 'Deadline August 1, 2026, correct?' Additionally, if a task needs multiple document attachments like invoice, proposal, and specification, the assistant must understand which files live in 1C or the company's file storage. This again depends on quality document management and storage integration.

Limitations are real. The assistant will not create a task if information is vague or clearly inaccurate. It cannot link a task to a project if the request does not specify one. It will not automate reassignment or reprioritization. Those are done through explicit commands or require scripting logic that sometimes costs more than manual clicking.

Implementation is phased. Start with creating new tasks, then add status updates and comments, then decide whether automating reassignment is worth the effort.

Security and data residency: RF perimeter, self-hosted deployment, Yandex AI Studio

Customs declarations, counterparty data, and personal information of Russian citizens are covered by Russian law 152-FZ on personal data. Sending them to OpenAI or Anthropic clouds overseas carries legal risk, imposes data localization requirements, and has reputational consequences. An internal AI assistant must keep sensitive data within Russian territory, inside the client's perimeter.

A common problem exists with popular agent frameworks like LangChain and LlamaIndex. By default they are configured to work with OpenAI API or OpenRouter. If a developer does not reconfigure explicitly, private client documents, employee requests, and model responses will flow to external services. This is a data leak in practice, regardless of legal technicalities.

We build the assistant on three pillars. First, a language model from Yandex AI Studio instead of overseas providers. Yandex physically hosts models in Russia, supports Russian language and domains (legal documents, Russia-specific content). Second, the agent framework runs self-hosted on the client's server. This is an open-source solution in the client's perimeter under IT department control. Third, all endpoints are fixed to internal IPs and Russian services, with traffic not leaving without explicit approval.

Deployment cost is lower than cloud Anthropic because there is no monthly bill for millions of API tokens. Yandex AI Studio uses a pricing model accessible to Russian businesses.

Self-hosted means the client owns full control, but also bears responsibility for infrastructure security, updates, backups, and monitoring. This is not cloud, where the provider manages. But in the context of 152-FZ and personal data protection, this control is exactly the advantage that justifies the effort.

Case study: from documents to automation (anonymous logistics client)

One of our clients works in logistics and handles hundreds of documents daily: contracts with counterparties, cargo specifications, customs declarations, commercial proposals, performance certificates. In the past, finding a needed document in the archive took hours, retyping standard forms was manual and error-prone, and tasks were tracked across different systems without synchronization.

The requirement was straightforward: give the team a tool that searches documents like a full-time employee, answers questions about clients and cargo directly in Telegram or a web interface, helps draft customs declaration templates, and automatically creates tasks in Bitrix24 for specific assignees.

We deployed a self-hosted AI assistant based on an open-source agent framework with a language model from Yandex AI Studio. We integrated it with:

• A RAG layer for semantic search across the company's document library
• 1C integration to pull counterparty, cargo, order, and balance data
• Tools for drafting customs declarations, proposals, and certificates
• Automatic task creation in Bitrix24 via API
• Interfaces through Telegram and a web portal
• Support for requests in Russian, English, and several other languages via the language model

The technical stack was driven by security requirements. Customs declarations and counterparty data are confidential information and have no place in OpenAI or Anthropic clouds overseas. We explicitly configured the assistant to use only Yandex AI Studio and deployed the framework on the client's Russian server. This completely eliminated the risk of personal data leakage.

Employees now ask in chat: what documents do we have for client X, or help me draft a proposal using latest prices for counterparty Y, or schedule a product balance check for Monday. The assistant finds the information, pulls the data, and outputs a draft or creates a task.

The effort paid off. Routine document searches no longer consume hours. Document drafts are prepared several times faster. Simple questions get answered in the messenger without context switching.

Honest limitations: when the assistant helps and when humans are needed

An assistant is a good helper for information search and draft preparation. The core rule is simple: where the end result requires a legal signature or carries financial responsibility, a person reviews and decides.

Language models can hallucinate and confidently deliver an incorrect answer by mixing real and invented details. On legal and financial documents, the employee always checks the output and bears responsibility.

Assistant quality depends heavily on document corpus preparation and freshness. If documents are disorganized, contain contradictions, or mix old and current versions, RAG will return noise. Invest time upfront in structuring, deduplication, and versioning with metadata. If you launch hastily on a dirty base, results will be poor.

Implementation is phased, not a big bang. Start with document search only, then add 1C lookups, then document drafts, then auto-tasks. Each stage should be calibrated and tested before expanding functionality.

Honestly assess whether you need this at all. If your knowledge base is 10-20 documents that people already know well, the assistant adds no value. If information changes daily and the base constantly becomes stale, the system will lose trust. If all operations are straightforward and easily formalized, basic automation without an LLM might suffice.