GENERATIVE ATTITUDE

Why the enterprise advantage is a hybrid control plane, not possession of the weights

Article GA-010 | Draft v1.1 | Evidence current to 26 October 2026

A bank downloads an open-weight language model, deploys it in a regional data centre and keeps every prompt inside its own network. The project is quickly labelled sovereign.

Then the harder questions arrive. Can the bank explain the model’s training provenance? Has legal approved the exact licence and derivative lineage? Who monitors upstream vulnerabilities? Which team can patch the serving stack without changing behaviour? Has anyone tested a rollback that restores the weights, adapters, prompts, retrieval index and policy together? What happens if the accelerator supply, repository or two engineers who understand the deployment become unavailable?

The model is local. Control is still incomplete.

This is the paradox at the centre of enterprise open-model strategy: more technical control often creates more organisational responsibility. Downloadable weights can improve confidentiality, customisation and negotiating leverage. They can also transfer validation, security, maintenance, resilience and evidence duties from a managed provider to the enterprise.

The useful question is therefore not, “Are open models sovereign?” It is, “Which layers of control can this organisation prove for this workload?”

That change of question leads to a different strategy. The competitive asset is not a preferred model family. It is a governed hybrid control plane that lets an enterprise choose between open and managed models, constrain each route, observe what happened, recover from failure and exit when conditions change.

Start by retiring the open-versus-closed shortcut

“Open model” is often used as if it described a single technical and legal state. It does not. At least five questions sit underneath the label:

1. Can the organisation obtain the model parameters?
2. Does the licence permit the intended commercial use?
3. Can it inspect and modify the relevant code and weights?
4. Is there enough information about the training process and data to study the system meaningfully?
5. Can it redistribute the original or a derivative?

The Open Source AI Definition 1.0 offers a useful normative baseline. It connects open-source AI to freedoms to use, study, modify and share, and it requires access to data information, code and parameters in the preferred form for modification. That is a stronger claim than “the weights can be downloaded”.

It is also not legislation, and it does not make the enterprise classification problem disappear. Model releases described as open can carry Apache 2.0, MIT or bespoke community terms. Conditions may vary by version, model size, commercial use or derivative lineage. Training information may be extensive, partial or absent.

The practical answer is to treat openness as an artefact-level record rather than a marketing category. For every approved version, record:

• the upstream repository and immutable commit;
• hashes for weights, tokenizer, adapters and serving image;
• the licence text and version;
• commercial-use, modification and redistribution rights;
• derivative lineage and inherited conditions;
• the model card and available training-data information;
• the evaluation date, owner and next review trigger.

Until that record supports a stronger term, “open weights” is usually the more precise description.

This precision is not an argument against open models. Weight access may enable isolated execution, version pinning, custom optimisation and provider substitution. Precision protects those advantages from claims the evidence cannot carry.

Consider a hypothetical multinational bank building a multilingual complaints assistant. In its first form, the system retrieves approved policy and drafts a response for an employee. A compact open model running in a controlled environment might reduce data movement and provide predictable capacity. A managed model might perform better on rare languages and complex reasoning. The decision cannot be resolved by attaching “open” or “closed” to either option. It depends on the exact task, data, rights, service level and control evidence.

Sovereignty is an evidence stack

Data residency is important, but it is one layer of sovereignty rather than its definition. A workload can run in an enterprise-owned facility and still depend on foreign accelerator supply, an upstream repository, unavailable training evidence, a restrictive licence or a small internal team. A managed service can reduce direct infrastructure control while offering tested regional processing, mature patching and contractual exit provisions.

A defensible sovereignty assessment separates eight dimensions:

Dimension	The question to answer	Example evidence
Data control	Where do prompts, outputs, retrieval data and logs travel?	Data-flow map, access policy, deletion test
Jurisdiction	Which laws, regulators and dispute forums apply?	Legal assessment, entity and processing locations
Infrastructure	Who controls compute, networks, keys and capacity?	Architecture, key ownership, stress-capacity evidence
Licence	Is use, modification and redistribution permitted?	Archived licence, counsel decision, lineage record
Operations	Can the service be patched, monitored and recovered?	Runbooks, service levels, restoration test
Upstream supply	Which hardware, libraries, repositories and maintainers remain critical?	Dependency inventory, alternatives, vulnerability process
Skills	Can the organisation validate and operate the system?	Named owners, support model, succession and training
Exit	Can it move within the required time and risk tolerance?	Tested substitute, migration runbook, last exit exercise

A dimension-by-dimension assessment should never hide a failed critical control. A service with a 30-minute recovery objective cannot compensate for an untested fallback by scoring well on licence openness. Each dimension needs an evidence link, owner, residual risk and review date. Management should define which dimensions are mandatory for the workload before comparing models.

This also clarifies portability. Interface portability means another endpoint accepts a similar request. Operational portability means prompts, safety policies, retrieval connectors, evaluation suites, telemetry and runbooks work with the replacement. Behavioural portability means the replacement meets the workload’s acceptance thresholds. Only testing establishes the last two.

European cloud-switching requirements, financial-sector outsourcing rules and operational-resilience regimes address parts of this dependency problem. None turns sovereignty into a binary certification. The enterprise still has to decide how much control the workload needs and prove that the service can meet it.

For the complaints assistant, the bank might require that customer text stays within approved regions, all policy retrieval is attributable, the service has a four-hour tested fallback and no model route may retain prompts. Those are workload controls. Whether the selected route is open or managed comes afterwards.

How to use the sovereignty scorecard without fooling yourself

A scorecard becomes dangerous when it turns eight unlike dimensions into one reassuring number. The purpose is not to award an overall sovereignty grade. It is to make hidden dependencies discussable and expose the dimensions where the workload cannot tolerate weakness.

Start by marking each dimension as mandatory, preferred or informational. A confidential research assistant may make data control and jurisdiction mandatory while accepting more upstream model dependence. A customer-facing service with a strict recovery target may make operational autonomy and tested exit mandatory. A specialised internal coding model may tolerate lower behavioural portability if repository access is tightly constrained and outputs remain subject to review.

Then separate control evidence from aspirations. “Runs in our cloud account” is an architectural statement. It is not evidence that the team can restore the service or obtain replacement capacity. “Uses an open licence” is a legal starting point. It is not evidence that every derivative and dependency has been reviewed. “Supports a compatible API” is an interface claim. It is not proof that another model will preserve behaviour.

A useful scorecard row therefore contains six fields:

1. the workload requirement;
2. the current design;
3. the evidence that the design works;
4. the accountable control owner;
5. the residual risk and expiry date;
6. the last tested exit or recovery result.

This changes the management conversation. Instead of debating whether a supplier or model is sovereign in the abstract, the team can see that data and jurisdiction controls are strong, upstream maintenance is weak and behavioural exit has never been tested. Remediation can then target the actual exposure.

The scorecard also allows fair comparison. A managed service may score well on operational resilience and skills, but poorly on upstream transparency or provider concentration. A self-hosted open model may reverse that pattern. The decision is defensible when the trade fits the workload’s priorities and the evidence is current.

Regulation follows roles and uses, not labels

Open publication does not remove regulatory responsibility. The EU AI Act distinguishes obligations for general-purpose AI model providers from obligations attached to downstream AI systems and their use.

As of 26 October 2026, the European Commission’s guidance on general-purpose AI providers explains that qualifying models released under a free and open-source licence can receive exemptions from certain documentation and representative duties when specified conditions are met. Providers still face copyright-policy and public training-content-summary obligations, and the exemption does not apply in the same way to general-purpose models with systemic risk. The Commission also states that its guidelines are not legally binding and that case-by-case assessment remains necessary.

Downstream duties require a separate analysis. An enterprise may be a deployer of an AI system, a provider of a downstream system or, depending on what it changes and places on the market, acquire additional provider responsibilities. A fine-tune for a narrow internal task does not automatically create the same role in every circumstance. Nor does downloading weights create a safe harbour. Purpose, modification, branding, distribution, capability and risk classification all matter.

Dates matter too. The Commission’s current AI Act timeline records that the 2026 AI Omnibus extended the application of Annex III high-risk rules to 2 December 2027 and product-embedded high-risk rules to 2 August 2028. These dates and interpretations should be checked again at publication and at any material system change.

In regulated finance, AI obligations sit alongside established accountability. For firms within its stated scope, meaning regulated UK-incorporated banks, building societies and PRA-designated investment firms with specified internal-model approvals, the PRA’s current SS1/23 applies five model-risk principles covering identification, governance, development and use, independent validation and mitigants. It states that its principles apply to models developed in-house or externally, including vendor models. The EU’s Digital Operational Resilience Act materials connect technology services and critical subcontracting to financial entities’ operational-resilience duties.

The practical lesson is simple: map the whole service chain. An internally hosted model can still depend on cloud GPUs, a public repository, an inference framework and external support. A managed endpoint can introduce sub-processors, silent upstream change and concentration risk. Governance should follow the actual service, not the procurement label.

Each workload therefore needs a dated role-and-obligation record. It should identify the model provider, modifier, system provider and deployer where relevant; describe the intended purpose and any high-risk classification; preserve the licence basis; map sector controls; and record legal or compliance conclusions. That record must be reopened when the purpose, model, tool authority or distribution changes.

The strategic platform is the control plane

A portfolio of several models is not automatically resilient. Without common controls, it becomes several APIs, identity schemes, log formats, safety settings and release processes. Teams duplicate integration work while central governance loses sight of actual use.

A hybrid strategy becomes credible when applications reach approved runtimes through a shared control plane. The control plane standardises the way workloads are admitted, evaluated, routed, observed and retired while keeping material differences between models visible.

[Figure 1: Governed hybrid AI control plane. Applications pass through common inventory, provenance, registry, evaluation, policy, routing, identity, telemetry and evidence controls before reaching approved open or managed runtimes.]

The control plane needs nine capabilities.

1. Workload inventory. Every service has a business owner, purpose, user population, data classification, jurisdiction, criticality, permitted actions, availability target, risk tier and regulatory-role record. Runtime discovery should identify unregistered endpoints and local deployments.

2. Acquisition and quarantine. Open artefacts enter through a controlled supply-chain path. Managed providers enter through data-flow, contractual, assurance and technical gates. The evidence differs, but both routes produce a comparable decision record.

3. Model and bundle registry. The registered unit is more than the weights. It includes tokenizer, adapters, inference image, prompts, retrieval configuration, safety policies and relevant dependencies. Versions are immutable. Stage labels represent governance decisions, not successful uploads.

4. Evaluation service. A reusable harness runs workload-specific tests against exact bundles and endpoints. Results retain the model version, dataset, prompt, decoding parameters, serving configuration and scoring method. Independent validators can reproduce or challenge the result.

5. Policy-aware gateway. Applications authenticate through a governed gateway. It checks workload identity, user context, purpose, data policy, rate and budget limits, and allowed actions. It can select only from approved candidates.

6. Routing and fallback. Policy defines the eligible set. Optimisation can then consider capability, latency, cost, availability and capacity within that set. Sensitive prompts must never move to an unauthorised route simply because it is cheaper or faster.

7. Identity and tool broker. Users, workloads, agents and tools have distinct identities. The broker issues or exchanges short-lived, scoped credentials and checks delegated authority for each action. Models never receive general production credentials.

8. Observability and incident control. Correlation identifiers connect the request, model, retrieval, policy decision, tool, approval and outcome. Incident controls can isolate a model, revoke an agent, disable a tool, freeze a route or restore a known-good bundle.

9. Evidence ledger. Licences, evaluations, approvals, exceptions, changes, incidents and exit tests are linked to the exact workload and version. The ledger answers not only what is running, but why it was allowed to run.

This architecture should have a stable core contract, not a lowest-common-denominator interface. Model-specific features can remain available through governed extensions. The common layer standardises identity, policy, evidence and lifecycle. It does not pretend that tokenisation, reasoning, safety behaviour, tool schemas or latency are interchangeable.

Route by workload, not by institutional preference

The same enterprise can reach different conclusions for different services. A routing decision should begin with non-negotiable constraints and eliminate ineligible routes before optimising performance or cost.

Decision factor	Question	Evidence before approval
Sensitivity	What data enters prompts, retrieval, logs and tools?	Classified data flow and retention test
Jurisdiction	Where may processing and support access occur?	Contract, architecture and access evidence
Capability	What must the model do reliably?	Versioned workload evaluation
Authority	What can the system read or change?	Tool scopes, transaction policy, approval design
Latency and capacity	What service level and stress volume are required?	Load test and capacity plan
Customisation	Is tuning or local adaptation genuinely necessary?	Benefit demonstrated against a simpler baseline
Licence and IP	Are use and derivative rights clear?	Archived terms and legal decision
Operability	Can teams monitor, patch and recover the complete service?	Runbook and restoration exercise
Concentration	Which providers, hardware and skills are single points of failure?	Dependency map and tested alternatives
Exit	Can the workload move in time without unacceptable loss?	Migration rehearsal and substitute test

For a low-impact drafting tool with volatile demand, a managed route may offer the best balance. For a stable, high-volume classification task using sensitive data, a smaller open model in a controlled runtime may be easier to constrain and validate. For a critical service, the portfolio may include both, with each route approved for a defined subset of traffic.

The gateway must not turn this decision into dynamic guesswork. It should receive a policy-defined eligible set for the workload and user context. Only then may a router choose among those approved candidates based on current latency, capacity or price. This sequence matters. Cost optimisation cannot override data or authority boundaries.

Fallback deserves the same discipline. A nominal secondary endpoint is not a resilient alternative if it has never passed the workload suite, cannot receive the data or behaves differently at critical edge cases. Test the fallback under realistic failure conditions. Record how prompts, retrieval, tool schemas and safety policies change. If the substitute meets a narrower service level, make that degradation explicit.

Controlled substitutability, not theoretical interchangeability, is the goal. The organisation should know which routes are approved, what each can do and how service changes when it switches.

Treat a model release as a supply-chain event

Weights are executable dependencies, not passive documents. They may arrive through mutable tags, use loaders that execute code and depend on a serving stack with its own vulnerabilities. The NIST secure development profile for generative AI extends secure software practices across the AI model lifecycle and is intended for model producers, system producers and acquirers. The joint NCSC secure AI development guidelines cover secure design, supply chains, documentation, deployment, incident management, logging, updates and maintenance.

A controlled path starts outside production:

1. A requester declares the source, immutable version, licence and intended workload.
2. An acquisition service downloads the artefact into quarantine, calculates hashes, checks available signatures, scans code and containers, blocks unsafe serialisation where possible and records dependencies.
3. An isolated evaluation environment loads the artefact without production credentials or sensitive data.
4. The approved release bundle links every component and all required evidence.
5. Production pulls only an approved bundle by immutable digest.

These controls do not prove that an artefact is benign. A hash proves that bytes match an expected object, not that the object is safe. A signature links an artefact to a key, not to a perfect development process. Provenance reduces ambiguity and enables investigation; it does not replace adversarial evaluation.

Evaluation begins with the job. Public benchmarks can screen candidates, but they cannot establish whether the complaints assistant cites the correct policy, recognises a vulnerable customer, avoids leaking personal data or escalates the right case. The enterprise test suite needs critical tasks, prohibited outcomes, harm scenarios and operating limits. It should cover capability, grounding, robustness, privacy, security, latency, failure, cost and recovery.

A release is the whole bundle. A new quantisation, adapter, system prompt, retrieval corpus, tool permission or inference image may change behaviour. Canary deployment and rollback are useful only when tied to business and safety thresholds. The previous known-good bundle must remain deployable.

Observability has the same system boundary. The evolving OpenTelemetry generative AI conventions include attributes for models, agents, retrieval, evaluation and tool calls. Yet prompts, outputs and retrieved content can contain personal or confidential information. Structured metadata, classifications, timing, token counts, policy decisions and tool events should be the default. Content capture should be purpose-limited, access-controlled, redacted where possible and retained only as long as necessary.

Agents turn model risk into authority risk

A chatbot produces content. An agent can retrieve confidential material, call tools, change permissions, send messages, deploy code or transfer value. Prompt injection can therefore become an authorisation attack, not merely a bad answer.

NIST’s 2026 concept work on software-agent identity and authority focuses on identification, authorisation, auditing and non-repudiation, including controls for prompt injection. The architectural implication is to treat each deployed agent or agent service as a governed principal.

Every invocation should carry the user, workload, agent, session and delegated purpose. Credentials should be short-lived and scoped to named tools, resources, operations, amounts and time. The tool broker evaluates policy on every call. Model text is never an authorisation token.

Untrusted content also needs a hard boundary. Emails, web pages, uploaded documents and retrieval results remain data even when they contain imperative sentences. Systems should isolate them and extract typed fields where possible. No retrieved text may change tool scope, policy or approval requirements. Detection models can add a signal, but the stronger control is architectural separation between untrusted content and the action channel.

Actions can then be classified:

• read-only retrieval within purpose and data scope may be automatic;
• a reversible internal draft may proceed with logging;
• external communication, permission change, code deployment, data deletion or value transfer needs stronger limits and sometimes human approval;
• prohibited actions remain blocked.

Human approval is not magic. Too many prompts create habituation, and reviewers may lack the evidence to spot a manipulated request. Approval should be reserved for meaningful risk tiers, display the exact proposed transaction and expire if anything material changes. Deterministic limits, separation of duties, revocation and emergency stop remain necessary.

The complaints assistant illustrates the boundary. Drafting a response from approved policy may be reversible and reviewable. Creating a case in the complaints system requires scoped write authority and validation of required fields. Sending the response to a customer is a separate, higher-impact action bound to an identified approver and the exact text. The model cannot approve its own progression from one stage to the next.

Accountability needs an operating model, not another committee

Hybrid AI distributes control ownership, but accountability must still resolve to one service owner.

The business owner approves purpose, service outcome and residual risk. The platform team operates the registry, gateway, evaluation and runtime services. Security owns identity patterns, threat models and incident coordination. Data owners approve retrieval, fine-tuning and telemetry use. Legal and compliance interpret licences, privacy and regulatory roles. Model risk or another independent function challenges the evidence. Operations owns availability, change and recovery. Procurement and third-party risk cover managed providers and critical upstreams.

A governance forum can decide portfolio policy and exceptions. It cannot replace named owners. Every production workload needs a concise approval record with:

• one accountable service owner;
• control owners and evidence links;
• known limitations and prohibited uses;
• monitoring and rollback thresholds;
• incident and fallback responsibilities;
• time-bound exceptions;
• a review date and current status.

The economics should be assessed at the same level. Open-model cost includes accelerators, energy, facilities or cloud capacity, under-utilisation, inference engineering, platform staff, security, evaluation, resilience and opportunity cost. Managed-model cost includes usage, commitments, data transfer, premium features, integration, assurance and switching. The useful measure is cost per accepted business outcome at the required service level, not the cheapest token.

Concentration must also be decomposed. Provider, cloud, model family, accelerator, repository, serving framework and scarce internal expertise can each become a single point of dependence. Moving from one API provider to one self-hosted model on one accelerator stack changes concentration. It does not remove it.

Measure governability as well as model quality

Accuracy, latency and unit cost matter, but they reveal little about whether the service can be controlled over time. A balanced operating dashboard should include four classes of measure.

Coverage measures show whether the control plane sees the estate. Examples include the proportion of discovered AI traffic associated with a registered workload, the proportion routed through the governed gateway and the proportion of production bundles with current owners, licences and evaluation evidence.

Control-performance measures show whether policies and operational mechanisms work. Track critical evaluation pass rates, policy denials later judged correct or incorrect, rollback time, restoration success, credential-revocation time and the age of open exceptions. Segment these measures by workload risk rather than averaging them into a benign enterprise number.

Outcome measures connect governance to the service. For the complaints assistant, that might include grounded drafting accuracy, escalation recall for vulnerable customers, employee override rates, unresolved citation failures and complaints reopened after AI-assisted handling. The model’s score is only one contributor.

Portfolio measures expose systemic dependence. Track traffic and critical workloads by provider, model family, cloud, accelerator stack and support team. Record how many critical services have a tested substitute and when each exit exercise last ran.

Metrics can also create perverse incentives. A team rewarded for fewer policy denials may simply weaken policy. A target for faster approval may encourage superficial review. Each measure therefore needs a purpose, an owner and a paired failure signal. The aim is not to prove that governance is working through a dashboard. It is to reveal where controls, evidence and service outcomes are drifting apart.

The strongest counterarguments improve the strategy

A serious hybrid strategy should survive criticism from both sides.

The first challenge is that managed providers can operate security, capacity, patching and assurance at a scale many enterprises cannot match. That is often true. Self-hosting should not become a prestige project. If an organisation cannot staff the runtime, monitor upstream change or exercise recovery, possession of the weights may reduce resilience. The control-plane approach accommodates this by evaluating the complete service and allowing managed routes to win where their evidence and operating model are stronger.

The second challenge is that a common gateway can suppress useful provider features and slow adoption. A rigid universal schema would do exactly that. The answer is a narrow stable core for identity, policy, telemetry, evidence and lifecycle, combined with governed extensions for differentiated capabilities. Teams can use a provider-specific feature without bypassing workload registration, data rules or incident controls.

The third challenge is cost. Open models can be economically attractive at high, predictable utilisation, particularly when a smaller model meets the task. They can also be expensive once capacity buffers, staff, resilience and upgrade work are included. Managed services can be attractive for bursty demand and fast-changing capability, but contractual commitments and switching costs matter. The enterprise should test scenarios rather than endorse a universal cost story.

Finally, human approval is sometimes presented as the cure for agentic risk. It is a necessary control for some actions, not a substitute for architecture. Reviewers can be fatigued, rushed or shown incomplete information. Approval works when the action is risk-tiered, the transaction is typed, critical parameters are visible, deterministic limits already apply and the authorisation is bound to the exact action.

These counterarguments do not weaken the case for governance. They prevent governance from becoming a synonym for centralisation, self-hosting or committee review. The objective is evidence-backed choice.

A 90-day programme should end in a decision, not a launch

An enterprise can make meaningful progress in 90 days if it treats the calendar as a sequence of evidence gates.

Days 0-15: visibility and ownership

Inventory models, endpoints, agents and priority workloads. Name the executive sponsor and the business, platform, security, legal, risk, data and operations owners. Define terminology, sovereignty dimensions and risk tiers. Select two pilot workloads with different control needs.

Gate 1: inventory coverage is evidenced, owners accept their roles and the pilot boundaries are explicit.

Days 16-30: control foundations

Create the registry schema, quarantine process, licence record, gateway identity and minimum telemetry. Version the first evaluation suites. Define promotion, rollback and incident thresholds. Map regulatory and sector obligations for the pilots.

Gate 2: candidate bundles are immutable, policies are traceable and the test plan is approved.

Days 31-60: constrained pilots

Evaluate an open and a managed route where the comparison is meaningful. Use synthetic, non-production or tightly controlled data. Test capability, safety, latency, failure, cost and operating procedures. Keep agent authority narrow. Exercise a canary and rollback.

Gate 3: results are reproducible, critical findings are resolved and residual risk is recorded.

Days 61-75: adversarial and operational readiness

Test prompt injection, retrieval poisoning, permission abuse, supply-chain compromise, provider outage, capacity stress, revocation, recovery and fallback. Complete independent challenge and service runbooks.

Gate 4: there is no unresolved critical control failure and the team has restored a known-good service.

Days 76-90: production decision

Review evidence, limitations, regulatory roles, total cost, concentration and exit. Approve a bounded release, extend the pilot, restrict the use or reject it.

Gate 5: the decision and its conditions are recorded. A pause is a valid result when evidence is incomplete.

This programme does not promise broad production adoption in a quarter. It creates a disciplined path to a decision that management can defend.

Control is the ability to change course

Open models can be an important part of an enterprise AI strategy. They can reduce certain data and provider dependencies, enable specialised deployment and create negotiating leverage. Managed services can offer capability, elasticity, mature operations and assurance that would be expensive to reproduce.

Neither route is sovereign by default.

Sovereignty is the evidence-backed ability to choose, constrain, observe, recover and exit for a defined workload. It depends on licences, people, infrastructure, regulation and operating discipline as much as on where the weights sit.

The board-level challenge is therefore not to select an ideology. It is to ask for proof. Which dependencies have been identified? Which controls are enforced? Which outcomes have been tested? Who is accountable? How quickly can the organisation recover or switch?

The enterprises that answer those questions well will gain more than model optionality. They will build the capability to adopt new models without rebuilding trust from scratch.

Selected sources

• Open Source AI Definition 1.0, Open Source Initiative.
• Guidelines on obligations for general-purpose AI providers, European Commission.
• AI Act implementation timeline, European Commission.
• SS1/23: Model risk management principles for banks, Prudential Regulation Authority.
• NIST SP 800-218A: Secure software development practices for generative AI, NIST.
• Guidelines for secure AI system development, UK National Cyber Security Centre and partners.
• New concept paper on identity and authority of software agents, NIST NCCoE.