Companies do not deploy a model; they build an LLM system

The model produces language. Identity, data, retrieval, tools, evaluation, monitoring and recovery determine whether that language becomes a reliable organisational capability.

A company selects a model.

The procurement discussion focuses on benchmark scores, context size, pricing and whether the model can be hosted privately.

Those are legitimate questions.

They are not yet a system design.

Employees need a way to authenticate. Documents need access controls. Prompts may contain confidential information. A retrieval layer must identify current sources. Tool calls need permissions. Outputs need review. Model changes need testing. Incidents need evidence.

The model is one component inside that path.

The central test

A company has not deployed an LLM when an endpoint begins returning text. It has deployed an LLM system when the complete path from user authority to verified outcome can be operated and governed.

---

There are four common operating models

Public or commercial API

The organisation sends requests to a provider-hosted model.

This usually offers the fastest access to strong models and avoids operating accelerator infrastructure.

The organisation accepts dependencies around:

• provider availability
• pricing
• model retirement
• data handling
• regional service
• logging and retention terms
• rate limits
• interface changes

This can be a sound choice for low-risk or well-bounded uses.

It should be treated as a supplier boundary, not as infrastructure that has disappeared.

Managed private service

The provider operates the model through a dedicated, region-bound or enterprise-controlled environment.

This may improve identity integration, contractual controls and data isolation.

The underlying model and control plane can still be provider-dependent.

“Private” needs to be defined precisely:

• Are prompts used for training?
• Who can access logs?
• Which administrators can reach the service?
• Where are requests processed?
• Can configuration and evaluations be exported?
• What happens when the service ends?

Self-hosted model

The organisation operates model weights on infrastructure it controls.

This provides greater control over runtime, networking, logging and data paths.

It also creates responsibility for:

• GPU capacity
• drivers and inference software
• model licences
• security updates
• scaling
• availability
• evaluation
• performance tuning
• recovery
• specialist skills

Self-hosting changes the dependency.

It does not remove dependency.

Hybrid model platform

Many organisations will use several models.

A gateway may route low-risk tasks to a small local model, complex reasoning to a larger provider model and sensitive workloads to a private service.

This can improve flexibility.

It also means the organisation is operating a model-selection platform rather than one model.

Routing rules, evaluation and fallback behaviour become architecture components.

The reference architecture is larger than the model

A useful enterprise path looks like this:

User or application identity
             |
             v
Task and data policy
             |
             v
Prompt assembly and redaction
             |
             v
Retrieval and context controls
             |
             v
Model gateway and model
             |
             v
Tool authorisation and execution
             |
             v
Output validation
             |
             v
Evidence, evaluation and feedback

Every layer can improve or damage the result.

A strong model behind weak retrieval gives confident answers from the wrong documents.

A strong model behind broad tool permissions creates an unsafe agent.

A strong model without evaluation may change behaviour silently after an update.

The platform should make these layers visible rather than presenting the model as a self-contained intelligence service.

---

Identity determines whose authority the model receives

An employee asking for a document summary should only retrieve documents that employee is authorised to access.

The AI interface should not create a new path around existing controls.

This becomes difficult when retrieval systems build one combined index from many sources. If permissions are lost during ingestion, the model may reveal information through direct quotation, summary or inference.

Identity must remain connected through the request:

Person
  |
Role and current authority
  |
Permitted data
  |
Permitted model
  |
Permitted tools
  |
Recorded action

A company-wide assistant should not have one universal data identity merely because that simplifies retrieval.

The same principle applies to applications and agents.

Each acting system needs attributable, bounded authority.

Retrieval is a data-governance system

Companies often begin with an internal knowledge assistant.

The visible feature is question answering.

The difficult work is document governance.

The retrieval system must decide:

• which repositories are included
• which version is current
• how permissions are represented
• when deleted material leaves the index
• how duplicates are handled
• which metadata is preserved
• whether passages may cross project boundaries
• how citations point back to evidence

RAG was introduced as a way to combine model generation with explicit external memory, improving access to knowledge that is difficult to preserve or update in model parameters. (arXiv)

In an organisation, the external memory is not a neutral pile of text.

It contains ownership, classification, retention and access rules.

A vector database does not replace those rules.

It must preserve or enforce them.

The model gateway becomes a policy boundary

A model gateway can provide one organisational interface to several model services.

It may handle:

• authentication
• model selection
• rate limits
• cost budgets
• data classification
• redaction
• caching
• prompt templates
• logging
• fallback
• version pinning

This can reduce direct application dependence on one provider.

It can also become a critical control plane.

If every application sends unrestricted prompts through the gateway, it becomes a concentrated path for confidential data. If fallback silently changes models, behaviour may change during an incident. If logs store complete prompts, the evidence system may become a new sensitive-data repository.

The gateway should not be a transparent pipe.

It is an enforcement and evidence layer.

Companies use LLMs in several different roles

Internal knowledge assistance

The model helps staff navigate policies, technical documentation and project material.

Success depends more on document quality, access control and citations than on open-ended creativity.

Document processing

The model extracts, classifies, compares or summarises contracts, forms, reports and correspondence.

The system needs confidence thresholds, exception handling and review for material fields.

Customer or staff support

The model drafts replies, recommends knowledge articles or handles bounded requests.

The safest early pattern is assistance rather than unsupervised communication.

Software engineering

The model explains code, proposes changes, generates tests and assists investigation.

Repository access, execution isolation, code review and supply-chain controls matter as much as model quality.

Operational assistance

The model summarises alerts, correlates records, prepares change plans or explains runbooks.

It should not receive broad infrastructure authority merely because it produces convincing operational language.

Analytical work

The model helps structure questions, compare qualitative evidence and produce an initial synthesis.

Calculations, source facts and final decisions should remain connected to appropriate tools and accountable reviewers.

These are different systems.

A support assistant and an infrastructure agent should not share the same risk model because both contain an LLM.

---

Agents turn model output into delegated action

An agent combines a model with tools and a loop.

It can interpret a goal, select an action, observe the result and continue.

This is an important recent shift in enterprise AI. NIST launched an AI Agent Standards Initiative in 2026 focused on secure operation, interoperability, identity and open protocols, reflecting that agent systems create infrastructure questions beyond ordinary chat. (NIST)

A company agent needs:

• a distinct identity
• a delegating user or process
• task-specific permissions
• limited duration
• tool restrictions
• action budgets
• evidence
• a stop path

Do not give an agent a permanent administrator account.

Issue the narrow capability required for the current task.

The model may decide that a change is useful.

The authorisation system should decide whether that change is allowed.

Evaluation must follow the workflow

A model benchmark measures the model under defined test conditions.

A company deploys a workflow.

The workflow may include retrieval, prompts, tools, users and approval steps. Each can change the result.

Evaluation should therefore occur at several levels:

Level	What to test
Model	Basic capability and known limitations
Prompt	Instruction adherence and output structure
Retrieval	Relevance, access control and source freshness
Tool use	Correct selection, parameters and failure handling
Workflow	End-to-end task success
Human interaction	Correction effort and overreliance
Operations	Latency, cost, availability and recovery
Governance	Evidence, retention and accountability

A model update should not enter production solely because the provider describes it as better.

Run the organisation’s evaluation set again.

A model can improve on general benchmarks while regressing on the terminology, formats or refusal behaviour a company depends on.

Monitoring should capture outcomes, not only tokens

Operational dashboards often show:

• request count
• latency
• token consumption
• model errors
• provider availability

Those are useful platform measures.

They do not show whether the system is helping.

Outcome monitoring may need:

• unsupported claims
• retrieval failures
• human corrections
• rejected tool calls
• escalation rate
• task completion
• unsafe output
• model-version differences
• incidents by workflow

The difficult failures are often semantic.

The endpoint responded successfully. The answer was wrong.

A company needs a way to collect those failures without retaining more sensitive data than necessary.

Ownership must cross organisational boundaries

An LLM system often spans several teams:

• infrastructure operates compute and networking
• security controls identity and data paths
• data teams manage retrieval
• application teams build workflows
• legal or compliance interprets obligations
• business owners define acceptable outcomes
• users identify practical failures

If no team owns the complete service, every team can report that its component is healthy while the workflow remains unsafe or useless.

A named service owner should be accountable for:

• intended purpose
• evaluation
• data boundary
• model and supplier choice
• operational performance
• incident response
• retirement

Ownership does not mean that one person performs all the work.

It means somebody can coordinate the whole system.

A practical enterprise review

Area	Weak signal	Stronger evidence
Purpose	“Productivity assistant”	Defined users, tasks, exclusions and outcomes
Model	One provider was selected	Approved models tested against company evaluations
Data	Documents are connected	Provenance, permissions, retention and deletion are preserved
Identity	Users sign in	Authority follows the request through retrieval and tools
Tools	The agent can perform tasks	Short-lived, task-bound permissions and independent validation
Evaluation	Users like the demo	Representative tests, failure thresholds and regression history
Monitoring	Tokens and latency are visible	Outcome failures and corrections are measurable
Recovery	The endpoint has high availability	Configuration, indexes, evaluations and model routes can be reconstructed
Exit	Another API could be used	Replacement model passes the same controlled workflow tests
Ownership	Several teams are involved	One service owner coordinates the complete lifecycle

The company should own the capability, not merely access it

An API can be part of ownable infrastructure.

So can an open-weight model running on local GPUs.

Ownership is not determined by location alone.

It appears when the organisation can inspect the system boundary, govern the data, evaluate the behaviour, recover the service and replace major dependencies without losing everything it learned.

A company does not need to train a foundation model to own its AI capability.

It needs to preserve the parts that are uniquely its own:

• task definitions
• data contracts
• retrieval design
• evaluations
• operating policy
• tool permissions
• incident evidence
• transfer knowledge

Models will change.

Those assets allow the organisation to change with them.

One question for the next company AI review

Do not ask only which model the company is using.

Ask:

Which parts of the working system would remain if that model and its provider disappeared tomorrow—and which parts would have to be rediscovered from scratch?

---