Sovereign AI Procurement for Small Professional Offices

The supplier’s proposal looks reassuring. It carries a Swiss flag, calls the service “sovereign” and promises that customer data is never used for training. The partner reviewing it still cannot answer three practical questions: Can support staff open a client file? Where does an error trace go? What can the office take away if the service ends?

Those unanswered questions should not stop a small professional office from using AI. They should change how it buys. Sensitive files can support valuable document search, drafting and workflow assistance once the office turns broad claims into controls that a supplier can evidence and test.

Sovereign AI procurement is an acceptance process for data flows, access, operations and exit. The winning option is the one that meets the office’s requirements in its delivered configuration and can be operated for the expected lifetime.

An AI development engagement can turn the checklist below into a short proof using synthetic or redacted documents. For wider purchasing questions, AI agents procurement covers the business case and vendor fit. Here, the focus is narrower: verifying claims about control over sensitive information.

---

Start With the Work the Office Wants to Enable

Procurement gets easier when the team begins with a concrete workflow. A law office may want cited answers across one matter. A fiduciary may want a missing-document list for one client and period. A consultancy may want a first draft assembled from authorised project files.

Write down the documents involved, the people allowed to see them, the actions the assistant may take and the human approval that remains. This creates a control baseline that every supplier must meet. It also prevents an appealing architecture from acquiring more authority than the work requires.

Run the same baseline against three options:

• A local appliance that runs inference and retrieval in the office
• A Swiss-hosted private service with dedicated or logically isolated resources
• A managed enterprise service with contractual and technical controls

A local appliance may reduce routine transfer to a model endpoint and give the office direct control over network rules and updates. It also adds responsibility for patching, backup, monitoring and recovery. A mature managed service may operate those functions better. Procurement should compare evidence and operating capacity instead of ranking options by physical distance alone.

This distinction separates the article from the broader on-prem AI buying decision. The question here is how the office verifies what each option actually controls.

Turn Every Sovereignty Claim Into Evidence

Supplier language becomes useful when it points to a document, configuration or test. Any “sovereign” label should be backed by specific evidence for the version and deployment being purchased.

Supplier claim	Evidence to request	Acceptance check
Inference runs locally	Runtime inventory, network design and update configuration	Observe outbound traffic during inference and indexing
Data stays in Switzerland	Processing, support, subprocessor and backup locations	Trace each stored and transmitted data class
Customer controls access	Named privileged roles, key ownership and access logs	Test office, supplier and emergency accounts separately
The system is air-gapped	Physical and logical network design	Demonstrate routine operation, updates and support procedures
Data is never used for training	Contract terms and configuration for each data use	Check monitoring, debugging, logs and support as separate paths

Local inference says where model execution happens. Swiss residency says where a processing or storage step occurs. Operational sovereignty concerns control over identities, network policy, model and index files, deletion, update timing and support access. Air-gapped operation describes a topology with no routine network path. Each property can matter, and each requires different proof.

A supplier may meet some requirements through contract and others through configuration. Record both. If a claim cannot be demonstrated during the proof, treat it as an open requirement with an owner and deadline rather than filling the gap with a badge or company address.

Draw the Entire Data Flow, Including Support

Ask the supplier to map every place a prompt, document, embedding, output, account identifier, telemetry event or error trace travels or rests. The diagram should include the browser, connector, OCR service, vector store, model runtime, logging, monitoring, update service, remote support, backup and disaster recovery.

For each component, record:

• The operating entity and country where processing or storage occurs
• The data classes it receives, the purpose and retention period
• Privileged roles and whether office staff can disable remote access
• Subprocessors, optional flows and what happens when an external dependency is unavailable

The FDPIC cloud-processing checklist asks controllers to assess provider terms, processing countries, inventories, subprocessors, deletion or return, security and cooperation with rights requests or investigations. Those questions apply to services hidden behind an appliance interface too. A box in the office may still call an external licence server, send telemetry or open a support tunnel.

“No training” should occupy one row in this map. Training use is distinct from abuse monitoring, debugging, support, logs, backup and legal retention. The vendor should state the treatment of each path separately.

Then observe the delivered system. Capture outbound connections during inference, indexing, updates and a support session. Document expected destinations and block an unapproved flow to confirm how the product behaves. A diagram describes intent; the network test shows the configured route.

Test Administrative Access and Client Permissions

The acceptance pack should name every privileged role. Separate the office administrator, supplier support account and emergency account. Record who approves access, how it expires, which actions are logged and whether the office can disable the supplier path outside a maintenance window.

Ask who controls encryption keys, model files, index snapshots and remote-management certificates. A local appliance with a permanent vendor tunnel gives the supplier a different operating position from a device where the customer opens a time-limited, logged support window.

User permissions need equal attention. The assistant should receive the current caller identity and enforce access by user, group, client or matter before retrieval. Test search, chat history, citations, exports, logs and administrator views. If the identity or policy service is unavailable, the request should fail closed.

Revocation must take effect at query authorisation immediately. An index or cache may need time to catch up, so the stale copy must remain unreachable during that interval. Files already downloaded or exported sit outside this control. Continuing control requires a specific managed mechanism and its own test.

The FDPIC’s outsourcing guidance says a controller remains responsible for selecting, instructing and monitoring processors, addressing confidentiality and security, and checking cross-border disclosure. The exact controller and processor roles depend on the professional mandate and data flow. The contract should allocate the duties rather than assume them from the product type.

Inspect the Model and Software Supply Chain

Sovereignty can fail through components that never appear on the marketing page. Request the model name and version, licence, source of the weights, hashes or signatures, runtime dependencies, vulnerability process and update channel. Identify components fetched at runtime and any feature that stops when the supplier is unreachable.

The same review should cover OCR, embedding models, vector database, authentication, monitoring agents and backup software. Ask which elements are open source, proprietary or bound to a subscription. A local model may still depend on a hosted identity service or remote licence check.

Define who can replace the model and how the change is approved. A new model or parser can alter answer quality, context handling and data flows. The office needs a regression test against its representative documents before an update reaches production.

The NIST AI Risk Management Framework Core provides voluntary US guidance rather than Swiss law. It is useful here because it calls for clear roles, third-party supply-chain controls, risk-based testing, monitoring and planned decommissioning across the lifecycle. A small office can adapt that structure without turning it into a certification claim.

This software inventory also supports vendor independence. Self-hosted AI vendor independence explains why owning the runtime still leaves dependencies around hardware, frameworks and operational skills.

Price the Operating Model Alongside the Product

The quoted licence or appliance price rarely captures the whole decision. Ask each supplier to price or assign responsibility for encrypted storage, backup, network changes, identity integration, model and index updates, monitoring, support, staff training, incident response and exit assistance.

A simple first-year comparison should make the arithmetic visible:

purchase or subscription + integration + support + administrator hours × internal hourly cost + expected review hours × reviewer cost

Every number in the comparison should come from the firm’s quote or an explicitly illustrative assumption dated in the decision record. Include the cost of a realistic outage and the work required to restore service. Token fees alone cannot represent the total cost of a system that also needs secure operations and human review.

Ownership needs names as well as numbers. Assign responsibility for operating-system patches, model updates, index rebuilds, backups, key rotation, monitoring and incident notification. Define who can suspend inference, preserve evidence and restore service. A local appliance gives the office more of these duties, so its value depends on whether someone can perform them consistently.

Make the Supplier Pass a Short Acceptance Proof

Use synthetic client documents with known answers. The proof should reproduce the delivered identity configuration, network policy and support process closely enough to reveal missing controls. Record each pass criterion, observed limitation, owner and remediation date.

Include these tests:

1. Two clients or matters with overlapping names, tested for leakage through search, citations, history and exports
2. A permission removal that blocks the next query while indexes and caches update
3. An untrusted file containing instructions aimed at the model, with application permissions and tool boundaries still enforced
4. A cited question with known evidence and a second question whose answer is absent
5. A controlled service outage and backup restore on an isolated test instance
6. Outbound-traffic observation during ordinary work, updates and supplier support

The proof should also include representative languages and document formats. A polished answer to a clean English PDF says little about a scanned German table or handwritten expense note. Measure the task the office intends to buy.

Do not allow automatic public-cloud fallback for sensitive workflows unless the same data class and destination have been explicitly approved. A manual route in the existing source system is usually the clearest continuity plan for a small office.

Exercise the Exit Before Signing

An exit clause becomes credible when the office can exercise it. Before signing, ask for a test export of readable source documents, metadata, client or matter access lists, prompts where required, outputs and useful audit data. Confirm that staff can open the core records without the supplier’s proprietary control plane.

Embeddings often need to be rebuilt because they are tied to a particular embedding model and index design. Treat them as optional migration material rather than assuming portability. Record which configurations, evaluation sets and workflow rules can be exported, along with every proprietary element that cannot.

The agreement should define return or deletion of supplier-held copies and the evidence the supplier will provide. That evidence has practical limits for copies outside the supplier’s control, so the data-flow map must identify those earlier. Backups may also follow a scheduled expiry instead of immediate erasure. State the process and time window precisely.

Test a restore on a second runtime where practical. At minimum, verify that source documents, metadata, access lists and audit records remain readable and sufficient to rebuild the service. Include exit assistance and internal migration time in the cost comparison.

This exercise improves the current purchase even if the office never leaves. It exposes hidden formats, unclear ownership and missing records while there is still room to negotiate.

Buy the Evidence the Office Can Operate

Sovereign AI procurement gives a small professional office a disciplined path to useful AI on sensitive information. It replaces broad comfort with a reviewable decision: what data moves, who can reach it, which dependencies remain and how the office recovers or exits.

The local appliance, Swiss-hosted private service and managed enterprise platform can each be valid. Run all three against the same workflow, evidence pack and acceptance proof. Choose the option whose controls are demonstrated and whose operating responsibilities match the office’s capacity.

Keep the decision record after signature. Reopen it when the supplier updates a model, changes a subprocessor or proposes a new support path, then ask the same question again: does the delivered configuration still meet the controls the office accepted?