HAVAA is Yukon Labs' AI orchestration platform: one governed AI agent working across Telegram, WhatsApp, web, mobile and email, in any language. It drafts a reply in seconds, checks it against your policy before sending, and escalates to a human when the stakes require it. Every reply is logged with the policy it was checked against and the person who approved it. It runs entirely inside your own perimeter.

What is the difference between an AI agent and a chatbot?

A chatbot answers; an agent acts. A chatbot matches a question to an answer. An agent is given a goal, decides which steps to take, calls tools to do them, and continues until it finishes or hands over. The practical difference is accountability: because an agent changes things, it needs per-user permissions, a boundary on which tools it can reach, and an audit trail.

Can HAVAA run entirely inside our perimeter, with no data leaving the organisation?

Yes — HAVAA runs entirely inside your perimeter, and that is the default for banks and state institutions. The model, orchestration, retrieval index, embedding model and logs all run on infrastructure you control. The detail where most "private AI" claims fail: self-hosting the model while calling a hosted embedding service still transmits every document you index. HAVAA keeps the whole path local, enforced by network egress control rather than a setting.

Which LLMs does HAVAA support — can we bring our own model?

Yes — you can bring your own model. HAVAA treats the model as a swappable component behind a stable interface, so it runs open-weight models you host, models you have licensed, or a hosted API where that is legally available — and can mix them. That also makes it cheaper: most enterprise traffic is simple and routes to a small model, with a larger one reserved for the minority of requests that need it.

What is MCP (Model Context Protocol), and does HAVAA support it?

MCP is the open standard for exposing tools and data sources to AI models, and yes, HAVAA supports it. Its value is portability: a tool built once works with any compatible model. It is now genuine infrastructure — donated by Anthropic to the Linux Foundation in December 2025, backed by AWS, Google, Microsoft and OpenAI, and running at about 97 million SDK downloads a month.

How do you stop an AI agent from taking an action it shouldn't?

You stop an AI agent structurally, not by instructing the model. Three controls: tools are scoped per context, so an agent answering an HR question does not hold a payment tool; every action runs under the requesting user's permissions, never a shared account; and consequential actions need a named human approver. Anything enforced only by prompt wording is not a control.

What hardware do we need to run LLMs on-premise?

Running an LLM on-premise needs less hardware than most expect: one server with one or two high-memory data-centre GPUs serves a real internal deployment. Memory is the constraint: a 70B model needs about 140 GB at full precision but roughly 35 GB at 4-bit. Budget separately for the KV cache, which scales with context length times concurrency.

How well does HAVAA handle Azerbaijani-language content?

Azerbaijani is a first-class language in HAVAA, alongside English, Russian and all other languages, which is treated as a design constraint rather than an afterthought. It has to be: Azerbaijani is low-resource for language models, quality trails English, and the gap widens on banking and legal vocabulary. We test model and quantisation choices against Azerbaijani cases from your own domain before anything ships.

How long does a first HAVAA deployment take?

A first HAVAA deployment takes ten to twelve weeks to a production use case, assuming the deployment posture is settled early. Two weeks to define workload and build an evaluation set in the languages you serve, two to evaluate models, two to stand up the stack, three to build the use case with identity-aware retrieval and audit from the start. The second use case costs a fraction of the first.

Can HAVAA integrate with our existing systems — SAP, 1C, internal APIs?

Yes — HAVAA integrates with SAP, 1C and internal APIs. Each system becomes a tool with a defined schema, validated arguments and its own access rules, so an agent can read from SAP, 1C or a core banking system without any of them being exposed wholesale. The work is less about connectivity than about deciding which operations are read-only and which need a human approval gate.

Is our data used to train any model?

No — your data is never used to train or improve any model, ours or a third party's. It answers your questions and nothing else. On-premise, this is physical rather than contractual: the model runs on your hardware and there is no outbound path. We also prefer retrieval over fine-tuning, so a deletion request can actually be honoured — remove the document and the embedding and it is gone.

If the model produces a wrong answer, is there an audit trail?

Yes — every HAVAA request carries a full audit trail. It records who asked, what was retrieved, which model and version answered, which tools were called, what came back and what it cost. That is what reconstructs a specific interaction months later — the form a regulator's question actually takes — and what an ISO/IEC 42001 auditor asks to see. Log retention and storage location are defined as part of the deployment.

HAVAA is priced per deployment rather than per message, because the cost of an on-premise system is fixed infrastructure plus support, not consumption. The shape depends on deployment posture, the number of channels and use cases in scope, and whether we operate the platform or hand it over. Infrastructure is separate and yours. We scope against your real expected volume during the assessment.

Do we need a data lakehouse before we can deploy AI agents?

No — a data lakehouse is not a prerequisite for AI agents, and treating it as one delays the first deployment by a year for no benefit. What agents need is governed access to the specific data one use case depends on: an authoritative source, defined terms, per-user permissions and lineage good enough to explain an answer. That is a few weeks of catalog work, not a platform migration.

Air-Gapped AI: No Internet Egress

Air-gapped AI means every component runs with no outbound internet. What that actually requires, where sovereignty claims quietly break, and how to operate models with no egress.

Air-gapped AI means the entire system — model, embeddings, vector store, orchestration, logging — runs inside a network with no outbound internet connectivity, enforced by egress control rather than by configuration. Nothing leaves. Not prompts, not documents, not telemetry.

The requirement is common in exactly the institutions that most want AI: banks under Central Bank supervision, ministries handling citizen registries, defence and critical infrastructure. It is also the requirement that most enterprise AI architectures fail on a technicality, because sovereignty is usually claimed at the model layer while some other component quietly calls out.

This article is about what air-gapped actually requires, where the claims break, and how to run the thing once it is built.

The distinction from "on-premise"

These are treated as synonyms and are not.

On-premise means the software runs on your infrastructure. It says nothing about network behaviour. An on-premise deployment can still call a licensing server, pull container images, send telemetry, or use a hosted embedding API — and most do, by default.

Air-gapped means no outbound connectivity is permitted, and the permission is enforced at the network layer. The test is not what the architecture diagram says; the test is whether a packet can leave.

The practical difference shows up in a security review. An on-premise claim is verified by looking at where the servers are. An air-gapped claim is verified by looking at egress firewall rules and a packet capture, and that is the only verification worth accepting.

Where sovereignty claims break

Five specific places, in the order they are usually found.

The embedding API. The most common failure by a wide margin. The organisation self-hosts the language model, feels confident, and calls a hosted embedding endpoint during document indexing. The prompt stays inside; the document content leaves. The sovereignty claim does not survive a serious review, and the exposure is larger than the one that was avoided, because indexing sends every document rather than every question.

The managed vector database. Same shape. The vectors themselves are reconstructible enough to matter, and the metadata attached to them is usually worse — document titles, paths, permissions.

Telemetry and crash reporting. Frameworks and inference servers frequently ship with usage analytics enabled by default. The payload is small and can include prompt fragments, model names and error contexts. This is the one that survives a design review and is found later by a network engineer.

Model and dependency downloads. Pulling weights, container images or Python packages at runtime is an egress path. In a genuinely sealed environment these have to be mirrored internally and versioned, which is a supply chain process rather than a deployment step.

Third-party tool servers. Once models can call tools, any tool that wraps an external SaaS API is an egress path with a friendly name. MCP makes adding tools cheap, which makes this failure cheap to introduce.

The correct posture is to assume every component calls out until proven otherwise, and to prove it with egress rules that default to deny.

What air-gapped operation actually requires

Six capabilities. Absent any one, the deployment either is not sealed or is not operable.

Local inference. The model runs on your GPUs. Hardware sizing is the constraint that shapes the whole project: a 70B-class model needs about 140 GB at full precision and roughly 35 GB at 4-bit, and quantisation to 8-bit gives around 50% memory savings at roughly 99.9% quality retention — which is usually the right trade for enterprise workloads. The detail is in deploying LLMs on-premise.

Local embeddings. A self-hosted embedding model, sized far smaller than the language model and frequently forgotten in capacity planning.

A local vector store. Running on your infrastructure, backed up by your processes, subject to your access control.

An internal model registry. Weights, versions and provenance mirrored inside the perimeter, so that upgrading a model is a controlled internal operation rather than a download.

An internal package mirror. Container images, language runtimes and libraries. This is normally the piece that delays projects, because it is owned by a different team than the one building the AI system.

Offline evaluation. Your test set, your scoring, running inside. Any evaluation harness that calls a hosted judge model is an egress path and also a confidentiality problem, since the judge sees both the question and the answer.

The operational reality

Three things change once the perimeter is sealed, and they are worth planning for rather than discovering.

Upgrades are events. New model weights arrive through a controlled transfer, are scanned, registered and tested internally. This is slower than pulling a new tag, and it is the price of the guarantee. Plan a quarterly cadence rather than reacting to each release.

Support is different. A vendor cannot log in to diagnose a problem. Ask any prospective vendor to describe their upgrade and support process without internet access; the answers are revealing, and several products effectively cannot be operated this way despite claiming they can.

You own the observability. No hosted dashboards, no external APM. Metrics, logs and traces stay inside, which means the monitoring stack is part of the project rather than an afterthought.

The compensating advantage is worth stating: an air-gapped system has a dramatically smaller attack surface and a much simpler compliance story. There is no data processing agreement to negotiate, no cross-border transfer question, and no third-party subprocessor list. For an institution under Azerbaijan's Law on Personal Data — which permits cross-border transfer only in defined circumstances and prohibits it where national security or public order is threatened — that simplicity is frequently the deciding factor. The legal detail is in data residency in Azerbaijan.

The economics

Air-gapped deployment is often assumed to be more expensive. At sustained volume it is generally not.

The crossover is driven by utilisation. Self-hosted inference on an H100 runs around $0.73 per million output tokens at batch 1 and about $0.18 at batch 8, against dollars per million for frontier hosted models. Published break-even analyses put the threshold at roughly 2 million tokens per day for most configurations, and 2–5 million tokens per day on reserved capacity over a twelve-month window.

Two honest caveats. Those figures assume you keep the GPUs busy; an underutilised cluster is expensive per token regardless of the hardware. And they exclude the operational staff cost, which is real and is the line most business cases understate.

For an institution that has no choice about the perimeter, the economics are secondary — but they are usually better than expected, and worth putting in the paper.

How to sequence it

Start by establishing the perimeter before building anything in it. Egress rules default to deny, internal mirrors for images and packages, an internal model registry. Teams that build first and seal later discover three egress dependencies at the worst possible moment.

Then one use case, read-only, one domain. Local model, local embeddings, local vector store, permission-aware retrieval under the requesting user's identity from day one.

Then verify the seal empirically: packet capture during a full workload run, including indexing, evaluation and an upgrade. A design review is not verification.

Then extend. The second use case is cheap once the perimeter and the orchestration layer exist, which is the entire economic argument for building them properly the first time.

Key points

On-premise and air-gapped are not synonyms. Air-gapped is verified with egress rules and a packet capture, not with an architecture diagram.
The most common break is a hosted embedding API during indexing — which exposes every document, not every question.
Also check telemetry, runtime model and package downloads, managed vector stores, and tool servers that wrap external SaaS.
Six requirements: local inference, local embeddings, local vector store, internal model registry, internal package mirror, offline evaluation.
Upgrades become controlled events and support cannot log in. Ask vendors to describe upgrades without internet access before signing.
Economics are usually better than assumed above roughly 2 million tokens per day, provided the GPUs stay busy.

HAVAA is built to run entirely inside the customer's perimeter — models, retrieval and embeddings included — with no outbound dependency. Related reading: sovereign AI and deploying LLMs on-premise.

Air-Gapped AI: Running Enterprise AI With No Internet Egress