Before approving private AI infrastructure, put the decisions your business needs to retain into writing. Inference means running AI models to produce outputs. A useful proposal should explain where that work happens, who operates it, and how changes are approved.
On August 11, 2026, Mistral AI announced regional inference choices for businesses. Our view is that buyers should use this discussion to make their own requirements more specific. Terms such as "private" and "sovereign" become useful purchasing criteria when translated into decisions, responsibilities, and evidence.
Location and permitted access
Start with the required deployment location and the organisations authorised to administer it. Your business might require equipment at its own site or in a data centre it contracts and controls. Record who can grant access, change network settings, inspect operational information, and approve support sessions. Decide which actions your team keeps and which a service partner may perform. Ask for those permissions to be reflected in the operating agreement and the deployed configuration.
The practical question is who has authority when something needs attention. Define how access is approved, limited, recorded, and removed. If support requires customer approval each time, include the approval process in the operating plan. If remote access is restricted, agree which monitoring and recovery tasks remain possible and who will perform the others. These choices belong in the service discussion before a response commitment is agreed.
Models and change approval
Model choice needs the same clarity. Specify which models and versions are in scope, who evaluates a candidate, and who approves its use. Agree a supported update policy, including planned changes and security maintenance. Ask how your organisation can request a different model and what testing, configuration, and commercial review that would involve. Treat the ability to request a change, approval of that change, and ongoing support as separate decisions.
The application owner
Define the application boundary alongside the inference boundary. Name the owner of each application that will connect to the environment, including any chat client or business system. Record who manages its permissions, updates, stored conversations, attachments, and retention settings. Ask for a documented inference API and an agreed connection test. Then make responsibility for application behaviour explicit, including any workflow actions. A useful proposal gives each area an accountable owner.
Acceptance and recovery
Acceptance should describe a workload your team recognises. Choose representative tasks and agree how reviewers will judge output quality, waiting time, and usable capacity. Record the test conditions and who signs off. For later changes, agree what must pass before release, who can stop a rollout, and how an earlier supported configuration would be restored. Ask for a recovery procedure and an agreed way to verify it. Include the customer actions and access that procedure requires.
Capacity and the operating scope
Capacity planning starts with demand your business can describe: the tasks people will run, how many may run at once, the size of their inputs, acceptable waiting times, and service hours. Ask the supplier to document assumptions and show how the proposed configuration will be evaluated against them. Agree when utilisation will be reviewed and what would trigger a capacity discussion. Include the operating work in the comparison: monitoring, maintenance, recovery preparation, and support coverage.
Walk through one proposed change
Consider a planning example: the owner of a customer-selected document application wants to evaluate a different model. This is a hypothetical review scenario, not a report of a customer deployment or a performance result.
Start the request with the business task and why the existing accepted configuration is being reconsidered. Have the application owner identify representative inputs and what a usable result would look like. Ask the inference operator to identify the proposed model, runtime settings and resources needed for the evaluation. Keep those proposals separate from the configuration currently accepted for use.
Agree who will review output quality, check the application connection and assess waiting time under representative demand. Name the person who can approve the change, the maintenance window it requires and the conditions that would stop the rollout. Record the recovery procedure and the customer access or actions needed to carry it out.
Use a short decision record to make the review concrete:
| Field | What to record |
|---|---|
| Request | The workload and reason for the proposed change |
| Scope | The model, configuration and application connection being evaluated |
| Ownership | Who proposes, evaluates, approves and carries out the change |
| Evidence | Agreed checks, conditions, findings and unresolved questions |
| Recovery | Who can stop the rollout and verify restoration |
Carry unresolved entries into the next review with an owner and a next action. Retain the accepted decision with the operating documentation so a later request starts from a known configuration.
The control checklist
Bring the following checklist to a discovery meeting. For each answer, record the decision, its owner, the evidence required, and any unresolved dependency:
- Location and access: Where must inference run, who controls that environment, and who may administer or support it?
- Models and changes: Which models are supported, who approves updates, and what is the process for evaluating alternatives?
- Applications: Who owns each connected application, its information, permissions, updates, and business actions?
- Acceptance and recovery: What must the workload test demonstrate, who accepts it, and who can authorise rollback?
- Capacity and operations: What demand is the proposal sized for, what support access is assumed, and when will capacity be reviewed?
At LLM Machines, we configure and maintain private AI inference environments on infrastructure the customer controls. Our standard scope includes workload discovery, capacity planning, model serving, and ongoing operational support. Customer applications remain under customer or third-party ownership; workflow integration can be scoped separately.
If you are evaluating private AI infrastructure, bring the workload you want to run and the controls you need to retain. We can use that starting point to define the technical scope and responsibilities together.