Internal AI Assistant for a Logistics Company: Architecture, Integration, and Data Security

An AI assistant in logistics is not just a chatbot. It is an agent framework that lives on the company's server, speaks the language of employees, and has direct access to 1C, Bitrix24, and document archives. When a logistics specialist asks "what customs declarations did we file for contractor ABC last quarter", the assistant searches the document base, retrieves relevant files via RAG, and provides the answer. When a cargo summary is needed, the assistant queries 1C through REST API, processes the response, and answers in plain language.

In practice, the assistant covers five scenarios. First: document search across large libraries. Second: data export for orders, inventory, reconciliation from ERP. Third: draft preparation for standard documents (customs declaration, commercial offer, act) based on the knowledge base. Fourth: automatic task creation in the tracker. Fifth: cron automation and persistent memory. An employee speaks like a human, the assistant understands and acts.

What is an AI assistant for a logistics company: self-hosting architecture example

An AI assistant for a logistics company is not an autonomous robot, but a software agent embedded in your workflows and connected to your systems. Unlike public ChatGPT, such an assistant works only with company data: documents, accounting information, task tracker, regulatory databases. Staff communicate in natural language through familiar channels (Telegram, messengers, web forms) and get precise answers based on real company information, not internet data.

The system is built from three components. The first is an agent framework (open-source solutions like AstrBot, Hermes, or Nanobot) that orchestrates logic and plugs tools into the LLM. The second is a language model on Yandex AI Studio, a cloud service in Russia, which is critical for keeping personal data and customs information within the country. The third is a RAG system over your document library that lets the assistant search relevant materials instead of hallucinating answers. Integrated with these are tools (MCP or function-calling) for 1C and Bitrix24 integration, allowing the assistant to request live data about shipments, counterparties, inventory, and payment status in real-time.

What the assistant can do

1. Search and answers across a large library of internal documents - regulations, declaration templates, instructions, contract samples. RAG finds relevant fragments, the assistant reformulates them into a response.
2. Natural language queries to 1C and Bitrix24 - list active shipments for a counterparty, check warehouse inventory, view payment history, pull current employee tasks.
3. Help drafting standard documents - customs declarations, commercial proposals, work completion certificates based on system data and template base.
4. Auto-creation and task assignment in Bitrix24 - the assistant assigns tasks to specific employees, links to projects or counterparties, calls tasks.task.add.
5. Long-term memory and cron automation - the assistant remembers conversation context, can send scheduled reminders, automate recurring checks.

Customs declarations, counterparty lists, personal and financial data must not go overseas to OpenAI or other foreign services. For this reason, the LLM runs on Yandex AI Studio (servers in Russia), the framework is deployed on the client's server, and the endpoint is locked to the RF contour. Many agent frameworks default to sending requests to OpenRouter or OpenAI - such configuration must be explicitly changed, otherwise there is a risk of personal data and business information leaks.

It is important to agree upfront that the system has limits. LLMs sometimes hallucinate, so legal and financial documents require human review before submission (human-in-the-loop). Assistant answer quality depends directly on the quality, freshness, and structure of your document base. RAG requires corpus preparation: cleaning errors, proper structure markup, regular updates. Rollout happens in phases, speed depends on data volume and integration complexity. For simple processes or small document sets, an assistant may be an overkill tool.

• LLMs hallucinate, so human review is required before sending legal and financial documents.
• Answer quality depends on document base quality and freshness.
• RAG requires prior preparation and regular corpus updates.
• Rollout happens in phases depending on data volume.
• There are scenarios where an assistant is overkill.

In one of our logistics projects, we built an internal AI assistant for a company. The system let staff search a large library of internal and regulatory documents in one query instead of manual file hunting. The assistant retrieves counterparty, shipment, and order data from 1C in natural language, helps draft a customs declaration using templates and live data, auto-assigns tasks to Bitrix24. All of this runs on the client's server with LLM on Yandex AI Studio, meeting security requirements and keeping data confidential.

Document search and retrieval from internal knowledge base: how RAG works

RAG (retrieval-augmented generation) is a method that allows a language model to query a company's internal document base instead of relying solely on its training knowledge. For a logistics company with thousands of documents covering procedures, templates, regulatory requirements, and partner history, RAG becomes a critical tool.

The principle is straightforward. An employee asks the assistant: "What documents do we need to clear a shipment into Kazakhstan?" Instead of generating text from the model's memory alone, the system performs the following:

1. Converts the question into a numerical representation (embedding)
2. Searches for semantically similar documents in the local database (typically 5-10 relevant results)
3. Passes the retrieved documents into the LLM context
4. The model generates an answer based on the retrieved material
5. Returns the response to the user with citations and source references

Answer quality depends entirely on what is in the document base. If documents are well-structured, current, and properly organized, the assistant gives accurate answers. If the base is cluttered, duplicated, or outdated, results will be wrong.

For logistics, this mechanism solves concrete problems: searching through large archives (hundreds or thousands of SOPs, regulations, forms), instant access to customs rules without manual digging, source references so employees see which document the answer came from, and consistency since a maintained base keeps information reliable.

But RAG is not magic. The system depends on data preparation. It requires cleanup of the database (remove duplicates, obsolete versions), structuring (add metadata, dates, categories), regular updates (new regulations, procedures), and awareness of context window limits since LLMs can only process part of a document at once.

In a project with one of our logistics clients, RAG was deployed incrementally. First, we processed the core corpus: regulations, templates, reference guides. Then we added historical data about partners. Search quality improves as the base grows and gets cleaner. Errors drop when the database is current and well-organized.

Getting data from 1C and Bitrix24 in natural language: MCP tools and function calling

An AI assistant is useful not only for searching documents. A logistics company needs a quick answer to what stock is in the warehouse or when a shipment from a client will arrive. Instead of copying data into RAG, which adds lag and loses freshness, you can give the assistant tools to query 1C and Bitrix24 in real time. This is called function-calling: the LLM understands which function to call in response to a user's question, executes it, and returns fresh data. The open Model Context Protocol (MCP) standard lets tools work consistently, whether hosted locally or remotely but within the Russian cloud.

In 1C, a logistics company stores products, stock levels, counterparties, and orders. Instead of manually opening a reference book to search for a counterparty, a staff member types in chat: show me counterparty Romashka LLC with delivery address in Moscow. The assistant recognizes the request, calls get_counterparty(name, address_filter) in 1C, gets structured data (tax ID, payment schedule, credit limit), and presents it to the user. If there is a typo or no match, 1C returns an error; the assistant detects it and asks for clarification.

The same applies to Bitrix24. I need to assign Ivan to check documents for shipment 123. The assistant calls task.add, fills in the fields (responsible party, description, deadline based on context), and creates the record. This is not blind automation, but a helper ready for 90% of cases, letting the human confirm or edit.

Sample user queries

• What stock of product XYZ do we have in the central warehouse?
• When does the shipment from Romashka LLC arrive?
• What is the credit limit for counterparty MIR-2?
• Show me aged receivables for August
• Assign Ivan to verify documents for order 12345
• Create a delivery checkpoint for shipment 567

The main constraint: function-calling requires a well-defined API. If 1C has 50 fields in a reference but only 10 are documented, the assistant sees only 10. Integration takes engineering work: list of functions, signatures, parameter types, response schemas. Slow API calls also create noticeable latency for users. The LLM may misinterpret a question and call the wrong function. This requires testing and feedback in early stages. The key benefit: data stays in 1C. No exports, no sync jobs. A user query triggers the function, and you get fresh results instantly. Critical for logistics where situations change intraday. Over time, logs of successful calls help the assistant learn which queries map to which functions, improving accuracy.

Drafting standard documents: customs declarations, commercial offers, acts

The AI assistant helps logistics employees draft standard documents needed daily. It is not automatic submission to a client system or customs authority, it is a first draft that the employee reviews, refines, and submits themselves. The draft is built from three layers: document templates from the internal knowledge base, data on counterparties and shipments from enterprise systems and CRM, and context from similar already completed documents (RAG).

For example, when a request arrives, "Draft a customs declaration for LLC Logistics Pro, shipment Z-2501," the assistant pulls from enterprise data on the counterparty (registration details, tax ID, address) and shipment (HS code, value, weight, units). It then searches the RAG for examples of similar declarations from company archives, by HS code, commodity type, and counterparty. It fills in the data into a standard declaration template, following the style and structure used in past filings. Finally it sends the employee a draft with notes on which fields need attention and where verification is required.

Standard documents and data sources

The employee interacts with the assistant through a familiar interface: writes a natural language request, receives a draft, reviews it, and files the document. Here is how this works in practice:

1. Employee writes to assistant chat: Draft an offer for client MEGA, valid 30 days, use the terms from the December offer to ALPHA
2. Assistant finds MEGA contact info in enterprise systems, pulls December ALPHA offer examples from RAG, fills in details, terms, and deadlines
3. Assistant sends a draft with notes on critical points: Check shipping terms carefully, Discount is set to 5 percent
4. Employee reads, edits, adds specifics for this offer, signs and sends to the client
5. If the draft is inaccurate (price or term hallucinated), the employee uses it as a starting point but verifies manually before filing

In one of our logistics projects, we applied this function to automate customs declaration and commercial offer drafts. A customs specialist used to spend significant time manually filling each declaration: searching past examples, copying registration data, updating details for the current shipment. With the assistant, a first draft appears in seconds. The specialist verifies fields prone to error (HS code, value, English name), and files the declaration. Hallucinations on critical data were rare thanks to RAG: the assistant learned from real company examples, not internet text.

Automating tasks and filing in tracker: Bitrix24 tasks.task.add and cron scenarios

Beyond document search and data retrieval, the assistant dramatically expands its utility by automating task creation directly in Bitrix24. When a manager instructs the assistant to 'assign an inspection of shipment 12345 to Maria by Friday', the system interprets the natural language request, extracts the task parameters (assignee, deadline, content), and calls the Bitrix24 tasks.task.add API to register the task immediately. This closes the loop between inquiry and action, eliminating manual data entry and ensuring accountability in real time.

The technical flow is straightforward. The assistant receives a command through the messenger or web interface, parses it with the LLM to identify task context (who, what, when, priority), formats the payload according to Bitrix24 REST specifications, and executes the API call under a service account. The task appears in the assignee's inbox with full description, linked documents (bill of lading, packing list, customs declaration draft if relevant), and deadline. If the LLM detects ambiguity, it asks clarifying questions in the same conversation thread rather than guessing.

Cron-based automation elevates the system further by handling repetitive workflows without human prompt. The framework can schedule periodic tasks, such as generating a daily list of overdue shipments or flagging contracts nearing renewal, and post them to Bitrix24 on a defined cadence. These long-running scenarios reduce manual triage and ensure that no recurring responsibility gets overlooked.

1. LLM interprets the manager's request and identifies task scope, assignee, and deadline.
2. System validates task parameters against Bitrix24 user directory and calendar (avoid impossible deadlines, non-existent team members).
3. API call formats the payload: task title, description, deadline, assignee, priority, linked objects (shipment ID, invoice number, document references).
4. Bitrix24 creates the task; the assignee gets a notification and can immediately see task details and attached context.
5. Assistant confirms task creation in the chat: 'Task assigned to [name], due [date]. Includes [linked docs].' for transparency and audit.

Security and audit trails are built-in. Every task created by the assistant is traceable: the system logs which instruction triggered it, what parameters were sent, and whether the API call succeeded or failed. Bitrix24 itself maintains version history, change logs, and task comments, so any corrections or follow-ups are recorded. This is essential for regulated industries like logistics, where customs declarations and financial transactions must be auditable.

Security and Personal Data Law 152-FZ: why self-hosted and Russian legal framework are critical for logistics

A logistics company processes customer personal data, contractor credentials, shipment information, and customs documentation. Under Russian Federal Law 152-FZ (Personal Data Protection), all this information must be processed with strict compliance to confidentiality and security requirements. If your AI assistant uses cloud LLMs like OpenAI or Claude, data is sent to servers overseas. This automatically violates the law and creates risks of significant fines, security incidents, and loss of client trust.

Cloud LLM services are trained on user queries, store processing logs, and there is no full guarantee that customs declarations, bank details, or client contact information won't end up in competitors' training sets or logs. Even if a provider promises confidentiality, data is physically outside RF jurisdiction.

The correct approach is to use a self-hosted agent framework (open-source, deployed on the company's own server) combined with an LLM hosted in the Russian Federation. Yandex AI Studio provides access to powerful language models with guaranteed RF-based hosting. Client data stays inside the company, and all processing runs on your own infrastructure.

A secure AI assistant architecture looks like this. On the client's server runs an open-source framework (e.g. based on Hermes or similar), which communicates with an LLM on Yandex AI Studio over encrypted HTTPS. The RAG index with client documents is stored locally, in the company database, not in the cloud. When an employee asks a question via the interface (Telegram bot, web app, or messenger), the framework retrieves relevant fragments from the local index, sends a request to Yandex AI Studio, receives the response, and returns the result without saving intermediate logs to cloud services.

1. Select an open-source agent framework that supports arbitrary LLM endpoints
2. Deploy the framework on a dedicated company server (on-premises or company data center)
3. Create an API key for Yandex AI Studio and explicitly reconfigure the framework to use this endpoint
4. Load the RAG index with company documents onto local hosting (not cloud)
5. Perform a security audit: check logs, configs, and network connections for data leaks
6. Integrate tools (1C API, Bitrix24 API) via local MCP proxies or function-calling
7. Test with real company data in a staging environment

In one of our logistics projects, we deployed exactly this architecture. The client works with a large library of regulations, declaration samples, and contract templates. After implementing a self-hosted assistant on an open-source framework with Yandex AI Studio, staff gained the ability to quickly search precedents in their documentation and receive declaration drafts based on company templates without fear of confidential information leaking overseas. All queries stay inside the company, log files are stored locally, and legal review remains in the hands of a specialist.

Honest limitations: LLM hallucinations, human-in-the-loop, RAG knowledge base requirements

LLM Hallucinations and Risk Points

LLMs hallucinate. This is not a bug, it is a property of neural network architecture. A model can generate a convincing but entirely fabricated answer. For logistics, where every document carries legal weight, this is dangerous. A customs declaration with the wrong tariff code, a contact person with an invented phone number, a calculated duty amount that came from nowhere, all are real risks. Therefore, humans cannot be removed from the decision chain, especially for financial and legal documents.

In practice, hallucinations emerge in three scenarios. First: when RAG returns incomplete or conflicting data, and the model attempts to fill the gaps with plausible fiction. Second: synthesis of numerical values (tax sums, commodity codes), where it is better to return an exact database result than to guess. Third: working with stale data, if the document base is not synchronized with company processes.

• Providing contact information for counterparties that do not exist in 1C
• Substituting incorrect units of measurement or currencies
• Synthesizing duty amounts instead of retrieving from actual tariff tables
• Inventing reasons for order delays when shipment history in the database is incomplete

Human-in-the-Loop as Architecture, Not Compromise

An internal assistant operates in advisory mode, not as a judge. An employee asks, sees the response, verifies it against source systems (1C, customs portals, internal wikis), and only then uses the result. This is not slowdown. This is shifting expertise to humans and routine to the assistant. The employee remains responsible for facts. The assistant saves time on search and initial information structuring.

In one of our logistics projects, customs and procurement staff received a web interface to the assistant. Each query about counterparties, shipments, or order status returned a structured response based on RAG and live 1C data. But this was a draft mode. The employee reviewed the information, confirmed it or updated the source, and only then did the result flow into an official document or client communication. Direct delivery of assistant responses to clients did not happen. This reduced errors in declarations and accelerated contract review cycles.

Preparing RAG: Data Quality Determines Output Quality

An assistant is as intelligent as its knowledge base is good. If documents are outdated, contradictory, or poorly tagged, responses will be inaccurate. RAG is not magic. It is vector search over relevant fragments, and output quality depends on input quality.

• Corpus cleaning: removing outdated versions, unifying terminology
• Metadata tagging: date, author, category (customs, counterparties, processes, access level)
• Text structuring: splitting large procedures into logical blocks with headings
• Embedding tuning: selecting vectorization model, chunk size, testing search quality
• Regular refresh: update cycles when processes or regulations change

Rollout is phased, not flipped on with a switch. Start with RAG over the document base (lowest risk), then add 1C and Bitrix24 integration, then task automation. At each stage, the client sees where the assistant truly helps, where its answers need verification, or where rules work better than LLM. This is a realistic approach, not a marketing promise.

Case study of a logistics company: document search, query execution, customs declaration filing

In one of our logistics projects, the company faced growing operational load. Employees repeatedly searched for the same information: delivery requirements to specific countries, customs compliance, patterns for filling invoices and declarations. Documents were scattered across dozens of files, emails, notes. Simultaneously, constant requests came in for order statuses, inventory levels, counterparty data from 1C and Bitrix24. Staff spent hours retrieving information instead of focusing on strategic development.

We built an internal AI assistant deployed on the client's own server. The core: Yandex AI Studio LLM, chosen because logistics data (customs declarations, counterparty information, personal data) cannot leave Russia under Federal Law 152-FZ and critical infrastructure requirements. The assistant connects to three sources: RAG-based document library (internal templates, references, rules), 1C (MCP tools for queries on inventory, orders, settlements), Bitrix24 (task creation and operation logging).

Employees ask the assistant in familiar chat: Telegram (accessible everywhere), web interface (in office), or company messenger. The assistant replies in the same channel. For documents requiring legal or financial review (customs declarations, acts, invoices), human-in-the-loop is built in: the assistant generates a draft, the employee edits and personally approves before sending to client or authorities.

Logistics handles personal data (counterparty names, contacts), commercial information (rates, delivery terms), and customs data. The choice of Yandex AI Studio is deliberate: the LLM is physically hosted on Russian servers and complies with Federal Law 152-FZ (personal data protection) and critical infrastructure guidelines. The framework is deployed on the client's own server, with endpoints locked within the Russian-regulated segment. Many open-source frameworks default to sending data to OpenRouter or OpenAI, but we explicitly reconfigured routes to prevent data leakage.

Employees now get answers in chat within seconds instead of hours searching folders and email. Routine work dropped. The model requires solid knowledge base preparation and ongoing tuning, but this fits naturally into company processes.