Frequently asked questions

Data governance is the operating model that decides who owns each data asset, what it means, where it came from and who may use it.

Day to day it changes four things: every important table has a named owner, contested terms like active customer have one approved definition, any figure can be traced back to its source columns, and access follows data sensitivity rather than old tickets.

No — OvalEdge is not a database, and it does not store your data. OvalEdge catalogs metadata about the systems you already run — names, definitions, ownership, sensitivity and how data flows.

It connects with read-only credentials, reads structure and statistics, and writes only metadata to its own store. Your data never moves, which is the answer to the first question every security review asks.

Yes — OvalEdge can be deployed on-premise or in an air-gapped environment, and that is the normal deployment here rather than an exception, which is why it survives the first filter in Azerbaijani banking and government evaluations.

It needs its own database and network access to the systems it reads. Nothing requires internet connectivity at runtime.

A typical OvalEdge implementation takes six to twelve weeks to a working catalog for one domain, with harvested lineage and a glossary people use.

Installing, connecting and harvesting take three to four weeks and are largely mechanical. The rest is the human phase — definitions, ownership, classification — which slows down in proportion to how many domains you attempt at once.

OvalEdge ships more than 170 pre-built native connectors, covering Oracle, SQL Server, PostgreSQL, Teradata, SAP, 1C, mainframe extracts, object storage, Snowflake, Databricks and the major BI tools.

Ask about your systems rather than the total, and ask specifically whether lineage is supported for each — many products can read a source's metadata but cannot parse its transformation logic.

No — a data catalog does not replace a data warehouse. The warehouse stores and serves data; the catalog stores metadata describing that data and everything in your other systems. They are used together.

Deploying a catalog changes nothing about your pipelines or reports — it makes them findable, documented and traceable.

A dictionary describes one database's structure for developers. A glossary defines business concepts like net exposure for the business. A catalog is the platform that spans the whole estate and holds both.

What makes the catalog more than a document is the binding: each glossary concept is linked to the physical columns that implement it.

Column-level lineage traces a single column from its source, through every transformation, to the figure in a report — which is exactly the shape of the supervisory question show us how this number was calculated.

Without it the answer is a reconstruction from memory that takes days. Insist on lineage parsed automatically from your SQL: hand-drawn diagrams are misleading within a year.

Data governance is owned by the business, with heavy technical support from IT.

IT can implement a catalog and harvest lineage; it cannot decide what active customer means. When governance sits entirely inside IT, definitions get made by people without the business context to make them, and the business ignores the result.

You do not need a full data governance programme before starting AI, but you do need governance on the specific data your AI will use — and that is more than most organisations have.

Gartner expects over 40% of agentic AI projects to be cancelled by end-2027, with inadequate controls among the causes. Catalog and classify the one domain your first use case depends on: a few weeks, not a year.

OvalEdge holds trilingual metadata as one canonical concept carrying a label in each language, rather than three parallel glossaries.

`müştəri`, `клиент` and `customer` share no characters, so no automated matching will connect them — a person who knows the business in all three languages has to decide they are one concept. Design for this on day one; retrofitting it is expensive.

OvalEdge supplies the evidence CBAR requirements depend on, though no software makes an institution compliant on its own.

CBAR's Regulation on Information Security Management in Banks, in force since April 2022 and built on ISO/IEC 27000, expects asset ownership, classification and access control tied to it. A catalog produces that evidence from the systems themselves rather than from memory.

Measure a data governance programme by behaviour change, not by row counts. A catalog with fifty thousand documented assets and no users is a more expensive spreadsheet.

The metrics that mean something: analysts checking the glossary before building a report, engineers checking lineage before changing a schema, and how long it now takes to answer a regulator's question about a figure.

A steward is a named person in the business accountable for a set of assets: approving definitions, confirming ownership, settling disputes. Roughly two hours a week.

Fewer than you expect — one per domain, so ten to twenty across a large bank. Make it part of an existing role, because a programme built around a few exceptional individuals collapses when two of them leave.

Yukon Labs is an OvalEdge implementation partner, not a reseller. We deploy, configure and operate OvalEdge inside your environment rather than selling a licence and leaving.

That means connectors against your real systems, lineage validated on your own transformation code, the multilingual glossary modelled correctly from the start, and the change management that decides whether the catalog gets used.

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.

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.

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.

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.

AI orchestration is the layer between models and your organisation: routing, tool access, state, permissions and audit.

You can call an API directly, and every project starts there. It stops working when the requirements arrive — look things up in our systems, only show what the user may see, explain an output from three months ago, nothing leaves the perimeter.

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.

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.

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.

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.

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.

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.

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.

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.

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.

A data lakehouse stores your data as open files on cheap storage while behaving like a warehouse when you query it.

The warehouse was reliable but locked your data in one vendor's system. The lake was cheap but had no guarantees, and most became swamps. The lakehouse adds a metadata layer over the files — an open table format — that restores transactions, schema control and time travel.

Trino is an open-source distributed SQL engine with no storage of its own; Starburst is its enterprise distribution, from the company founded by Trino's creators.

Starburst adds what regulated institutions need: row- and column-level access control applied across every source, 50+ supported connectors, parallel extraction from JDBC sources, caching and commercial support. Running open-source Trino is legitimate if your access-control needs are simple.

Yukon Labs implements and operates Starburst deployments in Azerbaijan as a delivery partner: cluster sizing, connector configuration, access policy design, directory integration and handover — or ongoing operation.

What matters more than a badge in an evaluation is whether anyone in-region has deployed the product against a core banking system and a supervisory access-control requirement. A tool nobody local has deployed is a tool you will operate alone.

No — Starburst queries data where it already lives, so nothing has to be moved. That is the point of the architecture: it reads from each source reading from each source at query time. There is no persistent copy inside the engine.

That also makes it easier to defend on data residency than centralisation: nothing is relocated, so the architecture itself raises no cross-border transfer question.

Starburst, Databricks and Snowflake optimise for different things. If your data is already consolidated in one platform, that platform's engine is hard to beat on its own data. If it sits across many systems you cannot consolidate, Starburst is the strongest of the three and it is not close.

For supervised institutions there is a prior filter: Databricks and Snowflake have no realistic air-gapped deployment.

Iceberg is an open table format — a metadata layer over Parquet files that gives you atomic commits, schema evolution, time travel and row-level deletes.

You need it to build a lakehouse; you do not need it to start using Starburst, which also reads Delta, Hudi, Parquet and ORC. The format debate is settled in Iceberg's favour. The live question in 2026 is which *catalog* you commit to.

Yes — Starburst Enterprise can be deployed on-premise, running on Kubernetes in your own data centre: coordinator and workers are containers, and object storage can be MinIO or Ceph rather than a cloud service.

Nothing requires internet connectivity at runtime. This is the normal deployment for Azerbaijani banks and government institutions.

There is no practical limit, and a single query can join across as many as it needs. Open-source Trino ships 30+ connectors; Starburst extends that past 50.

The real constraint is the slowest source in a given query — which is why Starburst's parallel connections to a JDBC source matter more in a legacy estate than the connector count does.

Federated queries are slower than a well-tuned single-source warehouse query — but that is usually the wrong comparison. The alternative to a federated query is not a fast query; it is a three-week wait for a pipeline.

Trino pushes filters and aggregations down into each source, so it lands far closer to native performance than people expect. Measure total time to answer, not query latency.

No — Starburst does not replace your BI tool. It is a query engine, and your BI tool connects to it as it would to a database.

What changes is reach: the same dashboards can query across the warehouse, the core system and object storage without a pipeline being built first. Most first deployments migrate a set of existing reports precisely so the difference is measurable.

A full lakehouse migration is a multi-year programme that frequently does not survive a change in priorities — which is why we recommend not doing one.

Federate first: a query engine over the estate as it is delivers value in the first quarter and shows what people actually query. Then migrate individual datasets only where there is a reason. A first federated deployment is six to ten weeks.

Starburst applies one policy layer across every connected source, including sources whose own security model cannot express the rules you need.

Row- and column-level policies map to your existing directory roles, so a user sees exactly what they are entitled to regardless of which system the data came from. One consistent policy is far easier to evidence to a supervisor than the same rules re-implemented in six systems.

ISO/IEC 42001 is the international standard for an AI management system, and Yukon Labs is certified to ISO/IEC 42001:2023 — the first company in Azerbaijan to hold it.

Its normative core is Annex A: 38 AI-specific controls under nine objectives, covering policy, roles, impact assessment, lifecycle, data and third parties. An auditor does not test whether your AI is good — they test whether your governance is real.

The EU AI Act can apply to an Azerbaijani company: it reaches providers and deployers outside the EU where the output of an AI system is used inside the EU.

The timing changed. Regulation (EU) 2026/1744 moved high-risk obligations to 2 December 2027 and 2 August 2028. Article 50 transparency duties and GPAI enforcement were not deferred and applied from 2 August 2026. Penalties reach €35 million or 7% of worldwide turnover.

Azerbaijan's Law on Personal Data requires a lawful basis for processing, state registration of information systems that process personal data, respect for data subject rights and compliance with cross-border transfer limits. An AI system is not a special case under any of them.

Two points catch teams out: the basis for the original collection often does not extend to training or grounding a model, and adding AI to a registered system is a change to that system. General information, not legal advice.

Personal data may leave Azerbaijan only on specific grounds: the destination state provides adequate protection, the data subject has explicitly consented, or the transfer is necessary to perform a contract. Transfers harming national security or public order are prohibited.

The point teams miss: sending a document to a foreign AI API is a transfer. Encryption and no-retention commitments do not change that — and the same applies to embeddings and logs. 

An AI risk assessment is a documented evaluation, made before deployment, of what one specific AI system could do to the people and processes it touches — with a named approver and a date.

It covers intended purpose, foreseeable misuse, data provenance, the consequences of a wrong output, who can override it and how. Required for ISO/IEC 42001 and for high-risk systems under the EU AI Act. Done after deployment, it is an audit finding.

Document an AI system continuously, while it is being built, because every regime rewards contemporaneous records and punishes retrospective reconstruction.

Eight artefacts carry the weight: the AI inventory with owners and risk ratings, the risk assessment with an approver, the production approval record, data provenance, the human override mechanism, the incident process, request-level logs, and third-party due diligence. Provenance is the one that cannot be fixed afterwards.

Yukon Labs builds and deploys sovereign AI and data governance infrastructure for banks, government institutions and large enterprises in Azerbaijan that cannot send data outside their own perimeter.

Three things: OvalEdge for data governance, Starburst on Trino for federated analytics, and HAVAA, our own AI orchestration platform. All deployed on-premise. Yukon Labs is certified to ISO/IEC 42001:2023.

Yukon Labs is based in Baku, Azerbaijan, and serves Azerbaijan primarily along with the wider region.

Being in-region is not incidental: data localisation, Central Bank supervision, trilingual metadata and procurement rules are local constraints. A platform with nobody in-region who has deployed it is a platform you will end up operating alone.

Yukon Labs works with government institutions, and their constraints are the ones our architecture is built around: citizen data that cannot leave the country, sovereignty requirements that rule out foreign cloud, and audit expectations that require evidence.

National policy makes this concrete — the AI Strategy for 2025–2028 and a 58-initiative digital development action plan for 2026–2028, approved by presidential decree.

Yukon Labs works in banking and financial services, government and the public sector, telecoms, and large industrial and energy organisations.

Banking is where the deepest work sits: years of digitised data, expensive processes worth automating, supervisory pressure and the strictest deployment constraints — which is why almost every serious banking AI project here becomes an on-premise project.

Most engagements start with a scoped assessment: four to six weeks on one domain, producing a system inventory, harvested lineage for one real report, a classification of where sensitive data sits, and a gap analysis against your obligations.

It breaks a specific deadlock — the business case needs evidence, and the evidence needs the program. The output is something a board can approve against.

Yukon Labs offers both, and the choice is yours: we implement and hand over, or we operate the platform for you.

What we advise against is treating operations as an afterthought. The scarcest skill in this market is running an AI or governance system for a year — evaluation, drift monitoring, incident response. Systems with no owner for those questions decay quietly.

Yukon Labs does both. HAVAA is our own product, and we build the integration layers around the platforms we implement — connectors nobody supports out of the box, access-control mappings, evaluation harnesses in your languages.

What we do not do is rebuild what a mature platform already provides. Writing your own catalog turns a six-week implementation into a permanent obligation.

Yukon Labs works in Azerbaijani, English and Russian — in documentation, delivery and the systems we build.

That is a working requirement here, not a courtesy: a typical large organisation runs an Azerbaijani core system, a Russian legacy application and English cloud infrastructure at once, and someone has to decide, in all three, that they describe one thing.

Yes — Yukon Labs signs an NDA before any technical discussion as a matter of routine, and works under customer security policies including on-site-only access, least-privilege credentials and environments with no outbound connectivity.

Our own AI management system is certified to ISO/IEC 42001:2023, so the governance we ask customers to adopt is governance we are audited against ourselves.

Three shapes cover most Yukon Labs engagements: an assessment is four to six weeks, a first implementation is six to twelve weeks to something working and measurable, and a full governance programme across an institution is twelve months.

What we advise against is the twelve-month platform project that helps nobody until it finishes. Scope narrow, prove one real outcome, and let that evidence fund the rest.