# What 'Customer-Controlled AI' Actually Means for Finance > Control is not one hosting checkbox. Finance teams need visibility and authority across deployment, model routing, data access, and the business definitions an agent is allowed to use. Published: 2025-11-23 Updated: 2026-07-24 Author: Archie Norman (Founder, MLX) Category: Twin Tags: twin, customer-controlled-ai, finance-ai, data-sovereignty, cfo Canonical URL: https://mlx.systems/blog/customer-controlled-ai ## TL;DR - Customer control has to be assessed across four independent planes: the data boundary, model route, execution boundary, and approved business definitions. - A private deployment does not by itself govern what an agent believes a metric means; the Twin makes definitions reviewable, versioned, and attributable. - Control is deployment-specific: current configured MLX model routes use external providers, so the context sent to a model follows that approved provider path. --- When a CFO asks an AI vendor “where does our data go?”, encryption and compliance certifications are relevant answers. They are not complete answers. Finance also needs to know: - which source evidence the system stores; - where the worker executes; - which model receives task context; - which tools and actions are available; - what business definition produced the answer; - what evidence identifies the product and freshness used. That is the difference between a general assurance and an inspectable control model. MLX is designed around customer-controlled execution, but “customer-controlled” should not be treated as a slogan. It is a set of controls and deployment facts across four planes. ## 1. The Data Plane The first question is where business evidence is held and how it is scoped. Approved connectors land organisation-scoped evidence inside the selected MLX deployment boundary. That is different from asking an agent to improvise live calls across a ledger, CRM, and project system for every question. It gives the platform a controlled source from which reviewed business products can be derived and refreshed. Connector permissions and freshness still matter. Read access should be no broader than the use case requires, and a governed answer should expose the source watermark for the product it used. This also requires precise language about egress. Current configured MLX routes use external model providers, so the task context supplied to the selected model follows that approved provider path. Deployment, connector storage, and model egress are related decisions, but they are not the same decision. A private data store does not make an external model call private to that boundary. ## 2. The Model Plane No single model is permanently best for every workload. Capability, latency, cost, residency requirements, and provider policy change. MLX separates the governed business product from the configured model route. That means a team can evaluate a different eligible model without rewriting the definition of revenue, margin, or working capital. Changing a route is not automatically risk-free. A new model can behave differently even when the product contract and tools remain fixed. The right change process uses task-appropriate evaluations and a controlled rollout, not a blind configuration switch. The durable asset is the approved business context and its evidence. The model is a replaceable execution dependency. ## 3. The Execution Plane The execution plane is where the runtime and workers operate. Current MLX targets are managed deployments; the exact network and operating boundary must be established for the selected target. A customer-operated or on-premises topology should not be assumed from the architecture alone. The architecture separates product contracts from deployment configuration, which is a useful prerequisite for supporting different topologies. It is not proof that every topology is currently shipped. Across current targets, the core Twin lifecycle remains: 1. connect scoped evidence; 2. discover candidate business products; 3. review the proposed definition; 4. publish a stable product contract and governed relation; 5. validate it and, where defined, run product-specific evaluations; 6. let approved agents query the activated product. Private compute alone is not enough. A badly governed agent running in a private VPC is still badly governed. ## 4. The Knowledge Plane This is the control plane most “sovereign AI” discussions miss. An answer can stay inside your network, use your preferred model, and still be wrong because the agent invented what “active customer” or “contribution margin” meant. The Twin makes that knowledge governable. For each published business product, the organisation can review: - source mappings and joins; - grain and exposed fields; - business definitions; - freshness expectations; - validation evidence; - optional evaluation cases; - the owner and publication history. The governed query path then binds an agent to the activated product. The model requests typed fields, filters, grouping, and ordering. The runtime validates that request against the contract, injects organisation scope, and mechanically compiles a read-only query against the exact published relation. That is stronger than putting the definition in a system prompt. The prompt can guide behaviour; the product contract and tool layer define and enforce the boundary. ## Control Also Means Knowing What Is Not Guaranteed Customer-controlled AI should make its limits visible. A governed product citation can identify the product slug, version, published relation, source watermark, and the catalog and relation events behind it. That is useful evidence about the route an answer took. It is not automatically transaction-level lineage. If an operator must drill from an answer to an individual source record, the published product needs to preserve an appropriate source reference or lineage mapping. Otherwise the system should say that the evidence is unsupported. The same principle applies to actions. A deployment may allow a class of writeback capability, but the control plane grants only the intersection of what the client requested and the tenant policy permits. A particular connector may remain read-only. Human approval and tool-specific safeguards cannot be replaced by a general claim that “the agent is controlled.” ## What Inspectability Looks Like A controlled deployment should let an operator establish: - the session and run that produced an output; - the model route used for that run; - the tool calls and runtime events that were recorded; - the activated Twin product and version; - the relation and freshness watermark cited; - the permissions granted to the session; - the human review or approval state where one is required. That is more useful than claiming that every decision can be perfectly replayed. Model outputs may vary, external systems change, and not every product preserves row-level lineage. The goal is to retain enough structured evidence to investigate what happened and judge whether the answer stayed inside its approved boundary. ## Questions for a Vendor If you are evaluating AI for finance, ask: 1. Where do connector data, runtime state, prompts, and outputs each reside? 2. Which external model providers are configured, and exactly what context does each receive? 3. Can we choose and evaluate model routes by workload? 4. Where do workers execute, and who operates each part of this specific deployment? 5. Who approves the business definitions an agent uses? 6. Can the agent query only a published, versioned product rather than arbitrary warehouse tables? 7. Which product, freshness, permission, and run evidence is retained? 8. What does the system do when the requested evidence or action is unsupported? Customer control is not achieved by answering only the hosting question. Finance needs control of where the system runs, what it can access, which model it uses, and what the business data is allowed to mean. --- **Related: *[On-Prem AI for Finance](/blog/on-prem-ai-for-finance).*** The controls and validation required before treating a customer-operated topology as real. **Related: *[LLM-Agnostic by Design](/blog/llm-agnostic-by-design).*** Why model choice should be evaluated independently from the governed business contract.