Developing an AI Assistant for Manufacturing and Logistics: Secure, Integrated, in the RF-contour

AI Assistant for Production: Development, 1C and Bitrix24 Integration, Compliance with Russian Data Protection Laws

When a company has hundreds of documents, a contractor database with deal history, and complex data structures in 1C, hours are lost daily to routine tasks. Employees search through notes, message colleagues, manually pull up balances and settlements, retype identical fields in customs declarations. An AI assistant breaks this cycle. Instead of searching, an employee asks in plain language, and the assistant retrieves information from 1C, finds the needed document in archives, and drafts customs declarations or proposals within seconds. But it is not magic; it is a tool with clear boundaries.

Customs declarations, contractor details, employee personal data, and trade secrets remain on the company's server. The LLM operates through Yandex AI Studio, hosted in Russia. The framework is self-hosted and sends no requests to OpenAI, Anthropic, or other foreign services. This is not just convenience; it is a requirement of Federal Law No. 152-FZ and the internal policy of most production companies.

This article explains how such an assistant works, which tasks it realistically solves, which limitations are built into its architecture, and why some companies may find it excessive. We also show a practical implementation example so you understand the scope of real integration and where human coordination begins.

About the Author

This article was prepared by S2 Digital, a company specializing in integrating AI systems into production environments within Russia's regulatory framework. The team has practical experience with self-hosted agentic frameworks, RAG architecture, 1C and Bitrix24 integrations, and compliance with Federal Law No. 152-FZ when handling personal data and trade secrets across 5+ projects in logistics, manufacturing, and wholesale trade.

What is an AI assistant and when it's needed in manufacturing

Definition and Scope

An internal AI assistant is not automation run amok or employee replacement. It is a software agent living inside your company, on your servers, speaking Russian and understanding your specifics. It pulls data from 1C and Bitrix24, answers questions about your document library, helps prepare standard documents, and creates tasks in your tracking system.

Five Primary Use Cases

• Search large document libraries (manuals, procedures, contracts, reports, archived emails). Instead of digging through cloud drives and Bitrix24, employees ask in plain language.
• Quick data lookups on contractors, orders, shipments, inventory, or payables from 1C. The assistant assembles data via API and delivers it in Russian.
• Drafting customs declarations, commercial proposals, or work completion reports based on your existing document base and data. A draft, not a final submission.
• Automating routine work: creating Bitrix24 tasks, reminding about overdue documents, running scheduled checks.
• Telegram channels and a web interface instead of yet another corporate portal. People work in familiar places.

It looks like ChatGPT inside your intranet, but it is not. Cloud LLMs send data abroad, violating Federal Law No. 152-FZ. You need special architecture that keeps the LLM on a Russian server, integrates the assistant with 1C and Bitrix24, and ensures safe handling of confidential data.

How document base search works (RAG and vector databases)

Document search at scale usually looks simple: keywords, full-text search, a list of results. But when you have thousands of documents and search not by exact match but by meaning, standard full-text search breaks down. This is where semantic search comes in, and its main solution is called RAG, Retrieval-Augmented Generation.

RAG is an approach where the LLM doesn't answer from memory but first retrieves relevant documents from your database, extracts context from them, and then generates a response based on what it found. This solves two problems at once: the assistant answers based on your actual documentation, not imagination, and you control what data goes to which model. It doesn't leave your company and go to OpenAI or Anthropic's cloud.

How vector search works

Vector databases are at the core of RAG. The idea is straightforward: each document, or part of it (a paragraph, section), is converted into a vector, a set of numbers that encodes the semantic meaning of the text. Similar documents will get similar vectors.

1. A document goes through an embedding model (a neural network running locally or called to Yandex AI Studio). The model converts text into a vector of 384-1024 numbers depending on the model.
2. The vector is stored in a specialized database (Weaviate, Milvus, Qdrant, others). This database is optimized for fast similarity search.
3. When a user asks a question, the question is also converted to a vector using the same model.
4. The database finds N nearest vectors to the question's vector using cosine distance or similar metrics.
5. The found documents are passed as context into the LLM's context window along with the user's question.
6. The LLM answers based on the context provided.

This process is fast (milliseconds) and works even when exact keywords don't match. For example, a question about benefits for limited liability companies on simplified tax will find documents about simplified tax systems for LLCs, even though the wording differs.

How it works in our solution

In our architecture, RAG works like this: you upload your document library to the system (procedures, templates, typical responses, internal regulations). The framework, self-hosted on your server, automatically chunks documents and creates vectors for them. When an employee asks the assistant, the system retrieves relevant parts from your database, passes them to the LLM, and the model responds based on your documentation.

This means the assistant says only what's in your documents. Personal data, customs declarations, information about counterparties and shipments stay on your server and are not sent to the cloud.

Real-world example: logistics

In one of our logistics projects, RAG was used for searching across a large document library: customs declaration procedures, standard templates, regulations, quotation samples. An employee writes: how do I fill out a declaration for electronics from China? The system finds relevant documentation sections, passes them to the LLM, and it helps draft a version. All without data leaving your network.

Integration with 1C: retrieving data on counterparties and shipments in natural language

1C Integration: displaying data on counterparties and cargo in natural language

How the AI assistant accesses 1C data

Traditional 1C integrations often require complex ETL pipelines: data export, transformation, loading into storage. Our approach is simpler. When asked a question, the assistant doesn't search for a pre-built report; it uses a set of tools (MCP functions) that call 1C's REST API or web services directly. The employee's question goes to the language model, which determines what data is needed (for example, "product balance" or "counterparty history"), forms a query to 1C, receives the response, and transforms it into understandable text. It's like how a person browses 1C reference books, but instead of clicking, natural language is used.

Example queries and typical responses

Security and compliance with Federal Law 152-FZ

Counterparty, cargo, and invoice data contain trade secrets and personal information. Sending it to cloud ChatGPT or foreign services is not permitted. Therefore, we use an LLM deployed in the Russian Federation: Yandex AI Studio. The framework runs on the client's own server, the endpoint is fixed, and data does not leave the infrastructure. [Important about tools and hallucinations] If you deploy a framework (for example, AstrBot, Hermes), check its configuration. By default, it may route requests to OpenRouter or OpenAI. This is data leakage. Explicitly switch to Yandex AI Studio and check logs to ensure requests don't go to the cloud.

Help with typical document preparation: drafts of customs declarations and commercial proposals

Companies in logistics, trade, and manufacturing constantly need standard documents: commercial quotes, customs declarations, work completion certificates. Manually gathering reference data, finding the right fields, remembering which currency was used last time - this is routine work that consumes hours. An AI assistant can automate draft preparation, drawing on a library of successfully completed documents in your company and data already stored in 1C or your management system.

Take a commercial quote as an example. An employee writes to the assistant: 'Prepare a quote for Acme Inc, steel product, 10 tons, price 500 rubles per unit, delivery DAP Moscow'. The assistant pulls counterparty data from 1C: company details, bank, signatory. From your accumulated document library, it extracts historical pricing for similar goods and standard delivery terms. Based on this data, it generates a complete draft: number, date, validity period, payment terms, all company details. The employee opens the draft, reviews it, and if correct, signs and sends it.

With customs declarations, the process is stricter because a mistake can result in a fine. So the assistant creates a DRAFT, not the final document. Based on commodity codes, weight, value, counterparty data from 1C, and examples of successful declarations from company archives, the assistant fills most of the form: commodity codes, descriptions, duties, contact details. A customs specialist reviews the draft, makes adjustments specific to this shipment, and only then submits it to customs. This saves considerable time on routine work while preserving human control and responsibility.

• Commercial quotes (with pricing calculations, delivery terms, discounts)
• Customs declarations (commodity codes, value, counterparty details)
• Work completion certificates (service descriptions, timelines, amounts)
• Invoices (if not directly integrated with accounting system)
• Contracts (based on company standard templates)

Key point: draft quality directly depends on the quality of your knowledge base. If you have accumulated a large library of correctly filled declarations, quotes, and certificates over a year or two, the assistant will learn from them and produce strong drafts. If the base is small or unstructured, early on there will be more editing needed. This is completely normal and is part of the deployment process. Implementation happens in phases: first, collect and prepare historical documents; then train the assistant through RAG vectorization; then gradually expand usage and the list of supported document types.

In one of our logistics projects, the assistant helps document specialists prepare drafts of customs declarations and commercial quotes. Instead of manually gathering 1C data, searching archives on a network drive, and retyping every field, an employee gives the assistant a single natural-language instruction - and gets a draft ready for review in seconds. This freed the team to focus on substantive tasks: accuracy checks, customs negotiations, handling edge cases, and filing customs appeals when needed.

Integration with Bitrix24: task automation and work assignment

How the assistant integrates with Bitrix24

When an employee asks the assistant about shipment status or requests a quote, the assistant retrieves data from 1C via the RAG layer, analyzes it, and if it finds an issue or identifies needed action, it creates a task for a specific person through Bitrix24 API. The task arrives with full context: problem description, attached data from 1C, document links. The executor sees it in their tracker with a notification and can start work immediately without switching between systems.

What processes are automated

1. Weekly payment monitoring. The assistant checks all counterparties, identifies overdue debt, and creates a task for accounting with exact amounts and deadlines.
2. Stock control alerts. When inventory falls below the critical threshold, the assistant creates a task for procurement with product code, current stock level, and recommended order quantity.
3. Customs declarations. The assistant generates a draft based on accumulated knowledge base, then creates a task for a customs specialist to review and finalize before submission.
4. Shipment delay notifications. When delivery lag is detected, the assistant immediately creates a task for the logistics team with reasons for the delay and expediting recommendations.
5. Document preparation workflow. When a manager requests a quote or contract draft, the assistant pulls relevant 1C data, then creates a task for the responsible person to finalize and sign off.

Data security and audit trail

The assistant works with Bitrix24 through explicit role-based permissions. Each employee can assign tasks only to people in their department or authorized groups. All counterparty and shipment data stays within the Russian Federation perimeter: the LLM runs on Yandex AI Studio, the agent framework is deployed on your server, and API calls go only to 1C and Bitrix24 on your infrastructure. Every action is logged for audit: who made the request, which task was created, when, and with what parameters.

In one of our logistics projects, the assistant was integrated with Bitrix24 to automate task assignment. When a manager queried shipment status and a delay was discovered, the assistant did not simply display information - it immediately created a task for the logistics team to expedite delivery with full shipment context. This reduced response time between problem detection and corrective action launch, and significantly improved task visibility across the team.

Security and 152-FZ compliance: why the LLM must be in the RF-contour

Customs declarations, contractor data, contract numbers, invoice details, employee and customer personal data: all are sensitive information under Federal Law No. 152-FZ on personal data protection. Sending such content to OpenAI, Anthropic, or any service outside Russia means transferring it to a foreign operator and violating the requirement that Russian citizens' personal data be processed only within Russia. This requirement is especially strict for government contracts, classified data, and customs documents. If you work with budget organizations or financial institutions, requirements become stricter.

The LLM for an internal assistant must run on Russian territory. Yandex AI Studio provides language model access via API with hosting in Russia. Data is processed in Russia, logs are stored in Russia, and legal compliance is ensured. The assistant framework must be self-hosted, installed on the client's server, within its infrastructure. The entire circuit remains closed in Russia.

Here is what to check when selecting an LLM and configuring integration:

In practice, many agent management frameworks (LangChain, OpenRouter integration, built-in examples) route requests to OpenAI by default. If you use a ready-made example, your customs declarations can end up on servers in California. You must explicitly reconfigure the API endpoint, specify Yandex AI Studio, and verify no third-party integrations are redirecting traffic. Even with Yandex AI Studio, always check where requests actually go.

Language models make mistakes, hallucinate, invent details, and mischaracterize contractors. On legal and financial documents, a human must always review. The assistant drafts a customs declaration; the employee checks it, makes corrections, and submits. This is acceleration, not automation. Similarly for a commercial proposal: the AI assembles a draft from examples and 1C data, the commercial director finalizes and sends it.

Honest limitations: hallucinations, data quality, when an assistant is overkill

Why LLMs Hallucinate and What to Do About It

Language models do not know facts the way people do. They predict the next token based on patterns from training data, and sometimes generate text that sounds plausible but is factually wrong. This is hallucination. It happens because the model has no built-in fact checker and cannot distinguish I saw this in training from this is true. The more specific or exotic your question, the higher the risk. A query about market prices or contract terms can yield confidently stated nonsense.

RAG reduces hallucination risk by tethering answers to actual documents. If the answer exists in your knowledge base, the model can cite or paraphrase it. But RAG only works if document search actually finds the needed source. If your corpus is cluttered, scattered, or missing key sections, RAG pulls garbage and the model builds hallucinations on top. For high-stakes documents (customs declarations, contracts), human review is mandatory. The assistant drafts; the human reviews, corrects, and submits.

Knowledge Base Quality Sets the Ceiling

The assistant answers well only if your documents are clean, current, and well organized. A dump of PDFs, outdated manuals, or conflicting versions in different folders produces inconsistent and wrong answers. Building a production knowledge base takes time: audit existing documents, remove duplicates, tag metadata (date, author, category), split large files into chunks of 512-1024 tokens, set up updates when processes change. RAG is a search engine over your documents, not magic. Garbage in, garbage out.

Invest in corpus quality upfront. It pays dividends.

When an Assistant Is Overkill

• Simple rule-based logic: if your workflow is if customer type equals wholesale then apply discount X, a rules engine is cheaper and more predictable than an AI assistant.
• Rare edge cases: if employees ask complex questions once a month, they can use regular search or call an expert. No chatbot needed.
• Small stable base: if you have 10 key documents that never change, put them in a wiki. An assistant adds complexity without value.
• Frequent structured queries: if 80% of questions are select from customers where region equals X, write direct database or API queries. Let the assistant handle the remaining 20% of edge cases.
• Unreliable data sources: if your 1C or Bitrix has poor data quality and no one trusts the numbers, an assistant only worsens distrust with confident statements about bad data.

An AI assistant is not a solution for poor data or poor processes. It is an amplifier for clean, well-maintained systems. Deploying an assistant over chaos produces only confident nonsense at scale. Build the foundation first.

Phased Implementation, Measure Real Usage

Successful deployments start narrow and expand. Begin with one team or use case with a sharp, well-defined need and clean data. Let them use the assistant for a month. Gather feedback. Fix search errors. Retrain on user questions. Expand once you prove people use it and it saves time. Avoid big-bang rollouts where you launch company-wide and hope people figure it out. They will not.

Solution architecture: self-hosted framework + Yandex AI Studio + client documents

Solution architecture combines four layers: an open-source agentic framework deployed in a Russian regulatory zone; LLM hosted on Yandex AI Studio; a RAG engine indexing client documents; integration tooling with 1C and Bitrix24. The assistant runs as a service on your server, interacts with employees via messenger or web interface, and never transmits sensitive data to third parties.

Architecture Layers

• Agentic framework (LangChain, LlamaIndex, ReAct-style or equivalent) runs self-hosted; employees interact through Telegram, web UI, or corporate chat.
• LLM via Yandex AI Studio processes prompts and generates responses; all traffic remains within the Russian cloud.
• RAG index holds your company documents (contracts, regulations, guidelines, sample customs declarations, quotation templates); retrieval is semantic, powered by embeddings.
• Bridges to 1C and Bitrix24 (MCP, REST API, webhooks) give the assistant access to counterparty data, shipment details, orders, inventory, and tasks, enabling draft generation and task automation.

Data Flow Through the System

Typical Workflow

An employee asks the chat: "What are the payment terms in the contract with counterparty XYZ?" The assistant retrieves relevant contract fragments from the RAG index, fetches counterparty details from 1C API in parallel, sends context to Yandex LLM, receives a response (for example: "Net 30 days, 18% VAT, 30% prepayment"), and returns it to the employee. The counterparty name, contract details, and internal data never leave your server.

Honest Limitations

LLMs hallucinate and miscompose facts. On documents requiring legal or financial correctness (customs declarations, VAT calculations, large quotations), the assistant generates a draft; a human reviews and submits. Answer quality directly depends on the quality of your knowledge base; unstructured or stale documents will degrade retrieval. Implementation requires corpus preparation (cleaning, tagging, indexing), 1C and Bitrix24 synchronization, team training, and phased scenario rollout. For routine tasks (policy lookup) the assistant works well; for highly specialized problems (complex logistics routing) it may be overkill.

Real-World Example

In one of our logistics projects, an internal assistant helps employees search a large library of reports and procedures, retrieves counterparty and shipment data in natural language, generates draft customs declarations from templates and historical data, and auto-creates tasks in the tracker. The assistant reduced time spent on manual information retrieval and document drafting; the time savings were reinvested in verification and expert review, not replacing staff.

Real-world case: logistics and document management

The Initial Situation and First Steps

Our logistics client faced a typical problem: the company had accumulated a large library of internal documents, manuals, and reference materials, but finding needed information quickly was nearly impossible. The archive held hundreds of documents: customs declaration procedures, sample commercial proposals, cargo processing regulations, emails from customs officials, completed declarations spanning several years. Employees spent hours searching manually, scrolling through cloud folders, and calling colleagues for information. Simultaneously, time was wasted on routine tasks that could theoretically be automated: drafting customs declarations, pulling contractor and shipment data from 1C via basic queries, manually creating Bitrix24 tasks.

The first pilot scenario was chosen deliberately: document search. A narrow, well-defined task requiring no complex integration but solving an acute need. We started with corpus preparation.

Knowledge Corpus Preparation: 2-4 Weeks of Work

This was the most labor-intensive part of the project. The company's archives held roughly 2,000-3,000 documents in various formats: PDF scans of letters and memos, Word documents with procedures, Excel spreadsheets with pricing data, sample completed declarations. We conducted an audit:

1. Identified duplicates and outdated versions. The archive contained multiple versions of the same procedures dated different years. We kept only current versions.
2. Removed illegible scans. Some PDFs were so poor quality that OCR could not process them. We recommended rescanning or replacing with digital copies.
3. Tagged metadata. Added tags (document category, update date, author, scope) to improve search.
4. Structured large files. Split long manuals (20-50 pages) into logical sections.
5. Loaded into the RAG index. Selected a chunk size of 512-768 tokens to preserve useful context without overloading the model.

Afterward the knowledge base was ready. Preparation time: 2.5 weeks with 1-2 company staff deeply familiar with processes.

1C Integration and Search Functions: 1-2 Weeks

Once RAG was working, we added 1C integration via REST API. The framework gained functions to query:

• Contractor details and history by name or code.
• Inventory by product code, by warehouse or all.
• Order history for a contractor over a period.
• Payables, debt, overpayment.
• Shipment info: weight, volume, status, delivery date.

Two challenges emerged. First: 1C's API required explicit authentication and secure credential storage. Second: the model sometimes misinterpreted user requests, for example asking for inventory by product name instead of code. We had to disable and rewrite several prompts for more precise intent parsing.

Implementation Issues and Solutions

LLM hallucinations. Early on, the model sometimes invented data absent from documents and without querying 1C. For example, asked about a contractor's discount, it might answer 15% discount without this being written anywhere. Solution: we added explicit requirements in the prompt to cite sources and specify which document or API provided the answer. Without a source, the model must say it does not know.

Chunk quality. At 2048+ token sizes, vector search returned passages too broad and the model lost context. At 256 tokens, context was lost for large tables. The optimum turned out to be 512-1024 tokens depending on document type.

Knowledge base updates. When the client changed procedures or added new documents, the index had to be rebuilt. This was not automatic. We set up a semi-automated process: weekly checks for new files in a network folder and automatic additions to the index.

Misunderstanding limitations. Staff initially thought the assistant could write final document versions and submit them directly. Training and documentation were needed to clarify that the assistant drafts documents that humans review and edit.

Results and Team Adaptation

After the pilot phase (4-6 weeks of use by a team of 5), results were obvious. Employees saved 30-50 minutes daily on information searches. Instead of opening 1C and clicking through directories, they asked the assistant via Telegram. For customs declaration drafts, instead of manually gathering data from multiple sources, the assistant compiled them in a minute, and a human reviewed and clarified in 10-15 minutes instead of 30-40.

Team adaptation was quick because the interface was familiar (Telegram) and improvements were tangible. By week two, 80% of the target group used the assistant daily. By week three, they requested expanded functionality for other scenarios.

Expansion: Bitrix24 Task Automation

After search and data retrieval success, we integrated Bitrix24. The assistant gained the ability to create tasks for specific staff based on identified issues. For example: if past-due contractor debt exceeds 30 days, the assistant creates an accountant task with contractor and amount details. If shipment status exceeds delivery forecast by more than 2 days, it creates a logistics task to accelerate.

This required permission settings and role rules: the assistant cannot create critical tasks (payment, contract signature) but can create informational and routine ones. Logging all assistant actions allows tracking which tasks were created and who initiated them.

Scaling and Rollout

Within a month the pilot group was joined by a second team (logistics). Then a third (procurement managers). By month two's end, about 25 employees used the assistant. No additional problems arose because the base was prepared, integrations debugged, and training was brief (30 minutes per group).

Currently, six months post-launch, roughly 30% of the company accesses the assistant daily. Primary use cases: document search (50%), 1C data (30%), declaration drafting (15%), other (5%) is experimentation and non-standard requests.

Honest Conclusions and Limitations

The LLM still hallucina occasionally. Cases are rare (1-2% of responses) but they exist. All legally significant documents (customs declarations, contracts, claims) undergo human review before sending. This is normal.

Answer quality depends on source data quality. If a contractor is entered into the 1C directory incorrectly (typo in name, missing details), the assistant returns the same bad data. This is not the assistant's problem but the source's.

The assistant does not replace specialists; it amplifies them. Logistics staff no longer waste time searching shipment and contractor info and focus on decisions. Accountants do not search payables data but review assistant conclusions and prepare claims.

Implementation requires careful preparation. You cannot simply deploy the framework and expect miracles. Invest time in corpus prep, integrations, training, and critically, constantly listen to user feedback and improve the system.