Three questions every project starts with
We do not publish news for the sake of publishing. This section collects the working checks for the three subjects customers bring us: equipment for site protection, deploying a language model inside the customer perimeter, and the legal requirements that apply when data is processed. Every block ends with a link to the page that covers it in full.
These notes change as projects run. This is not a market overview; it is the list of things we ask you to clarify before the contract, because these are exactly the points that turn into an argument at acceptance.
Counter-UAS equipment: what the numbers in a specification mean
The first thing a buyer receives is a table with range, band count and battery life. Those three numbers answer no question about the site. Range measured on an open test ground changes with terrain, buildings and antenna height. Band count tells you how many switches the menu has, not which of them you are allowed to switch on at your location. Runtime depends on whether the unit runs continuously or only when a signal arrives.
So we start with a survey, not with a model. We look at where the perimeter runs, where vehicles approach, where cameras sit and where the sector points. We then record in the test protocol the conditions under which the stated values were obtained: height, direction, aircraft type, presence of a radio link. The factory test record ships with the equipment and carries values for your configuration rather than catalogue figures.
We also name the cases where jamming will not work. An aircraft controlled over fibre has no radio link to occupy. One flying on optics alone with no GNSS does not respond to navigation effects. A target outside the sector or behind terrain stays outside coverage. We state these limits before the order: a supplier promising absolute protection is not accountable for the result at any site.
Commissioning is a separate set of tasks. Radiating equipment needs clearance in the country of operation, and switching on unused bands can affect civilian networks. The regulator, not the seller, defines the procedure. We supply the technical data for the document set and do not take on permits.
The full breakdown is on Counter-UAS: three tiers and the limits. If the site already has security in place, see for integrators for how we work with contractors.
On-premise LLM deployment: what to verify before the contract
"Data never leaves your perimeter" sounds like a finished solution, but on its own it guarantees nothing. In practice it breaks into four checks: where the servers physically sit, who can reach the models and logs, where telemetry and updates go, and what happens to backups. If even one of those stays outside the customer infrastructure, the deployment is not local.
Before the contract we fix the diagram: node composition, network boundaries, port list, model update procedure and access roles. Then we run a load test against your request profile and hand over the record. It exists so that "why does a peak response take four seconds" is settled by measurement rather than impression. The operating manual comes with the diagram in Russian or English: action on failure, restart order, who calls support.
There are tasks where a perimeter is not the right answer. If a specific closed model is required and quality depends on it, an equivalent open replacement may not exist; it is more honest to discuss API access immediately. We say so before signing, not after hardware has been bought. The choice follows the task and acceptance criteria, not the licence price.
The diagram, load-test record and responsibility boundaries are covered on on-premise deployment. If data is already processed in company systems, the next step is 152-FZ and local AI.
152-FZ and AI: where localisation ends
Four misconceptions recur in almost every project. First: "a server in Russia satisfies the requirement". Database localisation is one condition, not the whole law. Second: "the vendor files the notification". The operator files it — the organisation that defines the purposes and the scope of processing. Third: "anonymised data can be sent anywhere". The method of anonymisation and the transfer procedure still have to be documented. Fourth: "a contract clause is enough". A contract does not replace the operator's internal documents.
Local deployment removes the question of sending requests abroad: the model and logs stay in your infrastructure. It does not remove the operator's other duties — notification, processing policy, an assigned responsible person, access rules, retention and destruction periods. We help with the technical side: the list of data fields in a request, the data-flow diagram, logging, and evidence that computation does not leave the perimeter. Legal documents remain with the customer, and we say plainly where that line sits.
A decision map is the practical way to check: which data is involved, where it originates, who processes it, whether third-party transfer is needed, what the journal records. That map serves both an internal audit and a regulator's request. Draw it before the pilot — redrawing the architecture after launch costs more than sketching it up front.
The four misconceptions, the decision map and the cross-border section are on 152-FZ and local AI: what the law actually requires. Our own processing policy is published in Privacy policy.
API or perimeter: choosing without paying for both
API access fits when the data may already go to an external provider, when time to start matters and when load is uneven. Billing is per token rather than per seat, so the team can grow without changing the budget. The endpoint is OpenAI-standard-compatible, so switching models does not require rewriting the application. Limits and usage are visible per key and project.
A perimeter is needed when requests contain personal data, when internal rules forbid external calls, or when a reproducible version of an open model under your control is required. That decision is about data boundaries and accountability, not about comparing price per million tokens. Many projects run a mixed path: a pilot over API, then a production perimeter once information security signs off.
Formats, documents and billing are on model access over API. For the contracting entity and its details see about AIO Keys.
What customers ask before starting
Where do we start if the task is not yet defined?
Describe the site or the process, not the model of equipment. We need three things: which data is involved, where it lives now, and what counts as a result. From those we propose a delivery format and name what must be clarified before the contract.
Do you provide legal opinions on 152-FZ?
No. We are responsible for the technical side: data-flow diagram, logging, compute boundaries and evidence that requests do not leave the perimeter. The notification, processing policy and internal documents remain the duty of the operator — the customer.
Can we try API first and move to a perimeter later?
Yes, and it is a common path. The endpoint is OpenAI-standard-compatible, so changing the model or moving to a local deployment does not require rewriting the application. Fix the acceptance criteria during the pilot so the result is not debated later.
Why do you not publish warranty terms or prices?
They depend on configuration, scope of supply and load profile. A figure without conditions becomes a promise nobody can verify. So the calculation comes first, then the terms are fixed in the contract before signing.
Do you work with systems already installed at the site?
Yes. Units and models fit into existing infrastructure: during the survey we look at camera placement, the perimeter and network boundaries so no dead zones are created. How we work with your contractor is agreed before work starts.
Describe the task — we return a check list and a delivery format
We do not pick a model from a catalogue. First the questions about data, boundaries and acceptance criteria; then the calculation and the documents.
Discuss a project