An LLM strategy is a dependency and governance map

The model is only one dependency. Data, licences, providers, runtimes, GPUs, evaluation, identity, energy, people and regulation determine whether an AI capability remains under organisational control.

An organisation announces an AI strategy.

The strategy names several use cases and a preferred model provider. It promises productivity, automation and new services.

It says little about who may send data to the model. It does not identify how outputs will be evaluated. The exit path is a sentence about portability. Nobody owns the retrieval index. The company assumes an open-weight model can replace the provider if required, but that alternative has never been operated.

The organisation has an adoption plan.

It does not yet have a control model.

The central test

An LLM strategy is credible when every important dependency has an owner, a boundary, evidence and a replacement path.

---

The dependency map begins before the model

A production LLM service may depend on:

Users and organisational identity
             |
             v
Source data and permissions
             |
             v
Retrieval, prompts and application logic
             |
             v
Model licence and model artifact
             |
             v
Runtime, accelerators and hosting provider
             |
             v
Tools and external systems
             |
             v
Evaluation, evidence and operations

A failure in any layer can make the service unusable or ungovernable.

The provider may remain available while the company loses access to its retrieval data.

The model may remain downloadable while the runtime no longer supports the chosen quantisation.

The application may continue answering while the evaluation set has become obsolete.

Dependency is not the same as weakness.

Every infrastructure system depends on other systems.

The strategic question is whether the dependency is visible, bounded and replaceable.

Open weights and open-source AI are different claims

Open weights generally means that trained model parameters can be downloaded under stated terms.

That can create meaningful options:

• local inference
• independent hosting
• private evaluation
• adaptation
• competition between operators
• continued access if one hosted endpoint disappears

It does not automatically provide:

• training data
• complete training code
• reproducible training
• unrestricted rights
• evaluation material
• a production runtime
• maintenance
• operational skills

The Open Source Initiative released version 1.0 of its Open Source AI Definition in 2024. Its definition goes beyond weight availability and requires the freedoms and information needed to use, study, modify and share the system, including sufficient information about training data for a skilled person to recreate a substantially equivalent system with the same or similar data. (Open Source Initiative)

Not every open-weight model meets that definition.

That does not make open weights worthless.

It means the organisation should state exactly what is open.

Common mistake

“We can download the model, therefore we control the AI.”

Better framing

Record which artifacts, rights and operating capabilities are available—and which still depend on the original developer or another supplier.

Data governance covers more than training data

Companies often ask whether a provider trains on their prompts.

That is important.

It is only one data question.

An LLM system may process:

• user prompts
• retrieved documents
• generated outputs
• tool arguments
• conversation history
• user feedback
• evaluation examples
• safety incidents
• fine-tuning data
• embeddings
• logs
• long-term memory

Each has a lifecycle.

The organisation should know:

• who owns it
• why it is collected
• which identities can access it
• where it is processed
• how long it is retained
• whether it enters model training
• how correction and deletion work
• what leaves the system at exit

Embeddings and retrieval indexes deserve particular attention.

They are derived from source data, but they may remain sensitive. Deleting the original document does not guarantee that every derived representation has been removed.

Data governance must follow the transformations, not only the original file.

Model governance begins with intended purpose

A model should not be approved “for the company.”

It should be approved for defined uses.

A model may be acceptable for:

• rewriting internal drafts
• classifying non-sensitive support requests
• answering from approved documentation

The same model may be unacceptable for:

• autonomous access decisions
• unreviewed legal conclusions
• processing restricted data
• controlling physical systems

The governance record should include:

Intended users
Permitted tasks
Excluded tasks
Permitted data
Required review
Approved model versions
Evaluation threshold
Incident owner
Retirement condition

This creates a boundary that can be tested.

Without it, success in one low-risk task gradually becomes assumed permission for unrelated high-risk uses.

Evaluation is a continuing control

A model evaluation is not a one-time procurement exercise.

Behaviour can change because of:

• model version
• system prompt
• retrieval content
• tool definition
• runtime
• quantisation
• application logic
• user population
• external environment

The organisation needs a repeatable evaluation set and a release decision.

NIST’s Generative AI Profile frames trustworthiness and risk management across design, development, use and evaluation rather than as a single pre-deployment certification. (NIST)

A practical evaluation record should identify:

• exact system version
• representative tasks
• known edge cases
• unacceptable failures
• human reviewers
• results
• accepted residual risks
• comparison with the previous release

A benchmark score without the workflow context is weak governance evidence.

Law applies to the use, not the marketing label

The EU Artificial Intelligence Act establishes a risk-based legal framework covering providers, deployers and other actors, with obligations depending on the role, system and intended use. It also requires providers and deployers to take measures supporting an appropriate level of AI literacy among staff and others operating AI systems on their behalf. (EUR-Lex)

The same underlying LLM can therefore sit inside different legal and operational contexts.

A drafting assistant and a system influencing access to employment are not governed merely by the model name.

The intended use, affected people, degree of autonomy and surrounding controls matter.

Governance should connect legal review to architecture artifacts:

• intended-purpose statement
• data map
• risk classification
• human-oversight design
• technical documentation
• event records
• evaluation evidence
• supplier responsibilities
• incident process

A legal conclusion that never reaches the deployment pipeline is not an operational control.

Agents introduce delegated authority

A chat system produces a response.

An agent may use that response to act.

Once models can access email, source repositories, infrastructure APIs, purchasing systems or identity platforms, governance becomes an authority problem.

NIST’s 2026 agent work highlights identification, authorisation, auditing, non-repudiation and prompt-injection controls as distinct requirements. Its wider AI Agent Standards Initiative also focuses on secure and interoperable agent systems. (NIST)

An agent should have:

• an attributable identity
• a clear delegating principal
• short-lived permissions
• explicit tool scope
• time and spending limits
• approval for high-impact actions
• evidence of each material action
• independent stop and recovery controls

The model should not be able to extend its own authority.

A prompt is not a security boundary.

Provider dependence should be measured through replacement

A strategy may claim to be provider-neutral because the application uses a standard API shape.

That is only one layer of portability.

The system may still depend on:

• provider-specific model behaviour
• proprietary prompt features
• tool-call formats
• content filters
• embedding dimensions
• fine-tuning interfaces
• log and evaluation systems
• context limits
• latency assumptions
• regional availability

Replacement should be tested.

Take the organisation’s controlled evaluation set and run it against another model or provider. Measure output quality, tool behaviour, cost, latency and operational work.

The alternative does not need to be identical.

It needs to preserve the capabilities the organisation considers essential.

An untested fallback is not a fallback.

It is an idea.

---

Sustainability belongs in model selection

AI infrastructure consumes electricity through training, inference, data movement and the data centres supporting those activities.

The International Energy Agency’s Energy and AI report examines rising data-centre demand and the relationship between AI deployment, energy security, emissions and infrastructure planning. (IEA)

The sustainable response is not simply to select a provider that markets renewable energy.

Architecture decisions influence demand:

• use a smaller model when it meets the task
• avoid long context when retrieval is sufficient
• cache stable results
• batch non-interactive work
• route simple tasks away from expensive reasoning models
• limit agent loops and retries
• retire unused indexes and experiments
• measure useful outcomes rather than request counts
• run local hardware at meaningful utilisation

An agent that calls a large model twenty times to perform a task solvable by one database query is not sophisticated infrastructure.

It is poorly governed demand.

Energy, latency and cost often point toward the same design improvement: do less unnecessary work.

Recovery must include the organisation’s AI assets

Keeping a copy of the model weights is not a complete recovery plan.

The service may also require:

• runtime and drivers
• prompt templates
• retrieval configuration
• source-document mappings
• vector indexes
• evaluation sets
• tool definitions
• identities and credentials
• policy rules
• release records
• monitoring and incident history

A recovered model that cannot access the correct evidence or reproduce the approved behaviour is not the recovered service.

The recovery exercise should rebuild enough of the system to run the controlled evaluations again.

“Endpoint responds” is not the success condition.

“Approved capability has been restored” is.

Exit should preserve what the organisation learned

The most valuable AI assets may not be the model.

They may be:

• the task definition
• curated examples
• failure cases
• evaluation criteria
• retrieval metadata
• prompt and policy design
• human-review procedures
• tool boundaries
• operating evidence

Those assets should remain portable.

They allow the organisation to change models without beginning again from demonstrations and opinions.

A supplier exit plan should therefore cover more than exported conversations.

It should preserve the organisation’s ability to reproduce and evaluate the capability elsewhere.

A practical governance map

Domain	Evidence to retain
Purpose	Approved tasks, users, exclusions and outcomes
Model	Exact version, source, licence and release decision
Data	Inputs, retrieval sources, retention and derived assets
Identity	User, workload and agent authority
Evaluation	Test set, criteria, results and regression history
Tools	Permitted actions, approval rules and execution evidence
Operations	Capacity, latency, cost, failures and recovery
Security	Threat model, incident process and stop controls
Legal	Role, intended use, documentation and responsible owners
Sustainability	Model size, workload class, utilisation and energy decisions
Exit	Alternative model, portable assets and tested transition

A governance programme should produce these artifacts through normal operation.

It should not exist only as a policy document.

The LibreInfra test

LibreInfra’s position is direct: infrastructure should be ownable, open by design, evidence-driven, recoverable, governable and transferable—and ready for AI without losing control.

Applied to an LLM system, that means the organisation can answer:

• who has authority
• which data is used
• which model produced the result
• how behaviour was evaluated
• what evidence remains
• how the service is recovered
• how the model or supplier is replaced
• whether another qualified team can operate it

The organisation does not need to own every GPU or train every model.

It needs to own the capability to make those decisions.

One question for the next AI strategy review

Do not ask how many AI use cases the organisation plans to launch.

Ask:

Which dependency—model, provider, data, runtime, evaluation, identity or specialist knowledge—could currently prevent the organisation from changing course, and what evidence shows that dependency is under control?