The BYOK model

BYOK stands for bring your own key.

It means you hold the inference contract with the model provider. Yig does not operate model infrastructure. When the reasoning core calls a model, it calls your model — using your API key, under your data handling agreement, governed by the terms you accepted with your provider.

This is not a feature. It is a structural decision about what kind of company Yig is.

What BYOK means in practice

The inference contract lives between the customer and the provider. Yig is not a party to it. When you deploy Yig, you provide an API key for the model provider you have chosen. Yig uses that key to make inference calls during workflow execution. The calls go from Yig’s reasoning core to the provider’s API endpoint, under your account.

The model provider records those calls as yours. The data handling clauses that govern what the provider does with the data in those calls are the clauses you agreed to when you created your account — not Yig’s terms.

If you are a regulated institution that has negotiated enterprise data processing terms with a provider, those terms apply. If you have selected a self-hosted model, inference never leaves your infrastructure.

Yig does not intermediate the inference relationship. There is no Yig-hosted proxy through which your prompts travel. There is no Yig-side logging of model inputs and outputs. The reasoning core constructs a prompt, sends it to your provider, and records the output shape in the audit log — but the prompt content is not retained by Yig.

Why this matters for compliance

A hosted-SaaS inference vendor stands between the customer and the model. Every prompt and every response passes through the vendor’s infrastructure, under the vendor’s data processing agreement, governed by the vendor’s terms. A BYOK pass-through removes the vendor from the data path. The customer’s prompts go to the customer’s contracted provider, under the customer’s DPA, with the vendor seeing the output shape and nothing more.

BYOK converts the compliance question from “can I use Yig?” to “can I use [provider X]?” — a question that is usually already answered.

Consider a regulated EU bank evaluating Yig for an intercompany reconciliation workflow. The bank’s data protection officer has already signed an enterprise DPA with Azure for Azure OpenAI service, scoped to specific data categories, with EU-residency commitments and processor sub-list disclosure. The internal audit lead has approved Azure OpenAI for tier-2 financial data. The bank’s question is no longer “what does Yig do with our prompts?” The bank’s question is whether the existing Azure approval covers Yig’s invocations of it. The answer is yes, because Yig does not see the prompt content — only the input shape, the output shape, and the model identifier in the audit log.

This is a deliberate design. We are not in a position to obtain the variety of enterprise data processing approvals that each regulated institution requires. We do not need to be. You handle that relationship directly with the provider.

Switching providers

The workflow does not change when the model does. Because Yig is not in the inference business, changing model providers does not require changing workflows.

The template definitions, the tool contracts, the reviewer gate, and the audit log format are all provider-agnostic. Swapping from Claude to a self-hosted model — or from one frontier provider to another — requires only a configuration change: a new API key and a new provider identifier.

The reasoning core adapts the prompt envelope to the provider’s interface. Workflow outputs are structurally identical regardless of which model was used.

The audit log records which model provider and model identifier were used for each run. This means a future audit can verify that the approved provider was in use at the time of a specific close, without requiring access to the inference API.

What BYOK rules out

BYOK means Yig cannot fine-tune models on your data. There is no Yig infrastructure in which your prompts or outputs accumulate. There is no mechanism by which a model improvement we ship incorporates patterns from your close cycles.

This is not a concession. It is the correct architecture for finance. A model that has been fine-tuned on your financial data is a model that has learned your patterns — including the patterns that should not be learned, the exceptions that should not be generalised, and the one-time items that should never inform future outputs.

General reasoning capability applied to your specific context, within a constrained workflow, with your review gate — is a more defensible architecture than a personalised model that your team does not understand and cannot audit.

Supported provider categories

Three categories of provider, three jurisdictional shapes. The customer picks; Yig adapts.

Provider category	Examples	Jurisdictional fit	What changes about inference
Frontier hosted	Claude, GPT-4o, Azure OpenAI	Customer’s existing DPA with the provider applies; cross-border flows governed by that contract	Inference runs in the provider’s environment, region-pinned where the contract allows
Sovereign hosted	GLM, Qwen, Kimi, MiniMax, DeepSeek	Mainland China data-residency mandates; customer holds the provider relationship under PRC law	Inference stays within the sovereign provider’s environment; the customer’s domestic contract governs
Air-gapped self-host	Ollama, on-prem inference servers	No external API calls; inference never leaves the customer’s network	The customer’s infrastructure runs the model; Yig orchestrates from within the same boundary

A frontier hosted call from Yig Thinker is a single HTTPS request to the provider’s endpoint, signed with the customer’s API key, returning the model output to the reasoning core. A sovereign hosted call is structurally identical, addressed to a different jurisdictional endpoint, governed by a different contract. An air-gapped self-host call never leaves the customer’s network — the agent and the inference server share a boundary the IT admin defined.

The choice of provider is yours. The inference contract is yours. The data handling terms are yours. Yig is the reasoning layer on top — not the inference layer beneath.