A business's first local AI assistant can start as a single-user application on an office computer. The goal is straightforward: download a model, obtain responses on the chosen equipment and identify the model in the technical record. Internal documents and integrations follow that trial. The process below uses Ollama and an existing model, separating installation, conversation and team access.

Define the trial before installation

Choose three short requests from business work using demonstration data: summarising a procedure, classifying an enquiry and drafting a sales response. Record what each result must preserve. This makes the first installation verifiable and helps compare configurations. A greeting establishes basic operation, while the working trial should resemble the intended task.

Prepare a working account, SSD space and a record of the operating system, processor, memory and graphics card. A pilot with 32 GB RAM is an accessible assessment profile for a business; video memory and the engine determine which execution stages can be accelerated. Model files and context require resources beyond the installed application itself.

The first installation path

  1. Prepare

    Inventory the computer and define three demonstration tasks.

  2. Engine

    Official package, recorded version and running service.

  3. Model

    Exact tag, download and local-list verification.

  4. Trial

    Record the answer, context and CPU/GPU split.

Start with one user and demonstration data.

Install the engine from its official package

Ollama provides distributions for Windows, macOS and Linux. Select the official package for the computer's operating system and architecture, and check the supplier's identity. Record the installed version in the pilot sheet. On a GPU workstation, use a driver compatible with that system and engine backend; apply driver changes in a controlled manner before taking reference measurements.

Check installation in a terminal with ollama --version. Start the service once. On Linux, ollama serve supports manual startup; when the system or desktop application already manages the service, check the existing instance. Two instances attempting to use the same port can cause a startup error unrelated to the model.

Team working with laptops and documents in an office
Mikhail Nilov

Download an identifiable model

This walkthrough uses ministral-3:8b, a tag present in the Ollama catalogue when checked on 8 November 2026. Download it with ollama pull ministral-3:8b. After completion, ollama list shows available models. Record the tag and local identifier to recognise the actual artefact even after newer variants are published.

Downloading and first loading are separate stages. A file can be stored on disk before the model is loaded into RAM or GPU memory. Run ollama run ministral-3:8b for the trial conversation. Explicitly choose a local variant in the interface. Accounts or connectors using cloud services create a different processing path and require separate configuration.

Control context and the first working task

In the first conversation, submit a short text and request a bounded result: for example, three points preserving the conditions of a demonstration procedure. To test the local API, an integrator can send an object containing model, messages and stream: false to the local /api/chat route. The text response is in message.content.

Set a context appropriate to the trial, such as 4,096 tokens for short requests, and record the value. This is a pilot parameter rather than the model's general limit. Larger context requires additional memory. Keep the same limit when comparing two installations or models so that timing differences can be interpreted.

Three checks after the first response

  1. Identity

    Is the selected model and tag loaded?

  2. Execution

    Which resources does the engine report during the request?

  3. Outcome

    Does the result preserve the required working conditions?

A displayed answer starts the functional assessment.

Verify where the model executes

During a request, ollama ps shows the loaded model, context and processing split. Check whether execution uses the GPU, CPU or a combination. This helps explain timing differences and verify driver installation. Keep the output alongside free-memory information and the request submitted.

Run one trial after startup and another with the model already loaded. Record time to first text and to completion. If memory is exhausted, reduce context and active-request count, then repeat the same trial. A smaller model is worth assessing when the computer must also serve other business applications.

Add an interface while keeping services distinct

The engine's desktop interface may be sufficient for the first user. A web interface such as Open WebUI adds conversations and administration, but requires configuration of the engine connection, accounts and persistent storage. With containers, the computer's local address and the container's address belong to different network namespaces; verify connectivity from the component actually making the request.

Pin an application version and retain data in a persistent volume together with a configuration copy. Check the interface's licence and branding conditions. Keep the pilot accessible on its own computer. Making the service available across the business network follows authentication and access-rule configuration, with a separate trial for team users.

The order for connecting data

  1. 1 · Conversation

    Check the local model with demonstration text.

  2. 2 · Documents

    Add approved files and test retrieval.

  3. 3 · Team

    Configure identities, roles and shared capacity.

  4. 4 · Integration

    Connect applications with explicit permissions and validation.

Each stage has its own functional and access test.

Prepare the documentation and handover

Handover includes software versions, downloaded models, data locations, context settings and results from the three working tasks. Add startup and shutdown procedures, the responsible person and a restoration procedure. Check conversation persistence after restart separately. Predownloading the model supports a conversation trial without internet; document processing and other functions need their own equivalent tests.

WebHat uses a customised local AI system and provides consultancy on installation, equipment selection and adaptation to business work. A pilot can develop into a custom application with AI integration. Before internal data is used, define data flows and permissions for documents, logs and connected components.

Questions about the first installation

Does a local model require a cloud account?

The local path uses the installed engine and downloaded model. Cloud connections are selected and administered separately from this configuration.

Why can the first request take longer?

The first request can include loading weights. Compare a cold start separately from a request submitted while the model is already in memory.

What should I check if the graphics card is not used?

GPU compatibility, drivers, the engine backend, available memory and the service process configuration. Repeat the trial and examine the CPU/GPU split.

When should company documents be connected?

After verifying local operation, accounts, storage and access policy. Begin with a small approved document set and questions with known answers.