Private AI & Workspaces

Private AI on
hardware you control.

Run open models with sensitive documents on your workstation or private server. Search sources, prepare cited outputs and support research within an agreed processing boundary.

Your task

You need to work with confidential documents or research material while controlling where the files, model processing and outputs are allowed to go.

What you receive

A model and document workspace matched to your hardware, with tested tasks, access settings, local exports and operating instructions.

Scope, deliverables and acceptance checks

Scope and deliverables.

Your proposal identifies the included deliverables and their checks. The outline below helps define that scope.

  • Hardware and workload assessment: model and runtime matched to document formats, volume, language, concurrent users and acceptable response times.

    Acceptance criteria

    Run representative tasks on the intended equipment and record accuracy, response time and memory use.

  • Document intake: parsing, scanned-text recognition and cited search, with supported formats, update and re-index controls and visible failure states.

    Acceptance criteria

    Import a new file, open its cited passage, update the index and show an unsupported-file or unreadable-page state.

  • Repeatable tasks: reusable instructions and workflows with named input folders, permitted actions and output locations.

    Acceptance criteria

    Preview a permitted file task, inspect the result and demonstrate the agreed undo or recovery step.

  • Processing boundary: a documented offline workstation, private team server or explicitly connected profile.

    Acceptance criteria

    Check the actual document, processing and output routes for each profile; test external connections separately.

  • Outputs and activity record: reports, tables and drafts saved to agreed folders, with a record of what ran and any information sent outside the workspace.

    Acceptance criteria

    Open the exported result and trace it to the source and activity record.

  • Access and recovery: installation, user permissions, backup, restore and export arrangements.

    Acceptance criteria

    Verify an authorised account and test the agreed backup/restore or export route.

  • Performance assessment where useful: targeted retrieval, concise context and supported caching measured against a baseline on the agreed tasks.

    Acceptance criteria

    Compare the same task set before and after an adjustment; report observed changes without promised savings.

  • Research configurations: evaluate unrestricted or abliterated models for research requiring broader response behaviour. Record the selected checkpoint, licence and evaluation tasks.

    Acceptance criteria

    Evaluate the selected configuration on the agreed research tasks; record answer quality, refusal behaviour and limitations. Reduced refusals do not establish accuracy.

  • Handover: configuration, operating notes, update plan, walkthrough and the agreed acceptance demonstration.

    Acceptance criteria

    Complete the checklist below with representative non-confidential material.

First engagement

A scoped brief and, where needed, one working prototype. Review the task, content and result before extending the build.

At handover

The proposal names the editable source, configuration, assets and operating notes you receive. Support and maintenance are agreed separately.

What sets the fee and schedule?
  • Document formats and volume; scanned pages and languages.
  • Model size, target equipment, concurrent users and response requirements.
  • Access, backups, external connections and the agreed acceptance tasks.

These inputs determine the proposal. No fee or delivery date is fixed before the included work and dependencies are agreed.

Choose the operating boundary

Where the work runs.

The document, processing and output routes are agreed before installation. A locally installed interface does not establish local processing.

Scroll across for document, processing, output and connection details.

ModeDocumentsProcessingOutputsConnection
Offline workstationPrepared deviceLocal document processing and model inferenceAgreed local foldersInstallation and model transfer beforehand; core work must pass disconnected acceptance.
Private team serverCompany-hosted storageCompany-hosted processing within the agreed networkNamed team folders with access controlsCompany network for colleagues; remote and external access are configured separately.
Connected workspaceNamed local or company foldersLocal processing plus approved provider operationsAgreed folders; selected task or status messages sent through providersThe scope lists every connector, recipient and outbound payload.
Hosted processing, optionalSource location defined in the profileSelected prompts, excerpts or files sent to the approved model providerSaved locally or to the agreed serviceAn explicit separate profile; the offline profile never switches to it silently.
Document routes, logs and external providers
  • Synced folders, backups, activity logs and account access must follow the chosen handling boundary. The acceptance check inspects those routes as well as the main task.
  • A connected scope names the information sent outside: task requests, prompts, document excerpts, files or status messages. Only the approved payload and recipient are enabled.
  • Local processing still requires device access controls and an agreed backup and recovery route. Hosted processing has its own provider terms and must be explicitly selected.
Performance and optional model adaptation

Targeted retrieval, reused context and supported caching can be assessed against the same representative tasks. The report states the measured response time, accuracy and resource use; it does not promise a saving percentage.

Retrieval supplies source passages without changing model weights. Fine-tuning is considered only for a defined task that remains unmet, using separate evaluation examples and the applicable licence terms.

Disconnected acceptance checklist

Offline acceptance

Verify the offline workflow.

An offline scope covers document intake, scanned-text recognition where required, retrieval, model inference and output without cloud processing or an external runtime connection. The complete task is tested with external network access blocked. Access controls, backups and exported files are assessed alongside local processing.

  1. Cold start with external network access blocked. Load the required fonts, interface assets, document tools and model; inspect for attempted external requests.
  2. Import a new document, including a scanned page where recognition is in scope. Ask a question and open the cited passage.
  3. Update or re-index the document and show a clear failure state for an unsupported or unreadable input.
  4. Prepare an output, inspect its saved location and compare it with the source and activity record.
  5. Preview one permitted reversible file task, run it and demonstrate the agreed undo or recovery.
  6. Test any connected profile separately. Show the outbound payload, destination and required review before the external step.

These are commissioning and acceptance requirements. Desk remains a partial preview; its installed model answering, embeddings and scanned-text workflow have not completed disconnected acceptance.

Scope, exclusions and handover

Hardware purchases, new integrations, model adaptation, remote access and ongoing support are included only when named in the proposal. The Desk example does not establish acceptance of a client installation.

The proposal identifies the source, configuration, access and operating notes included at handover. Third-party software and model licences remain applicable. Maintenance, update testing and further development are scoped separately.

Before we begin

Questions about this scope.

Does offline really mean no internet?

The agreed offline workflow must run on the prepared device: document parsing, scanned-text recognition, search, inference and outputs. Installation, model transfer and optional updates happen beforehand. Acceptance uses a disconnected cold start, a new document and the required interface assets; the Desk preview has not yet passed those checks.

Read the acceptance checklist →
Can a team use the same workspace?

A private server can serve authorised colleagues on the company network. Document permissions, backups, remote access and external connections are specified separately. Team access alone does not establish an offline or confidential configuration.

Compare operating modes →
Is it trained on our documents?

Document retrieval makes approved files searchable and supplies cited context. It does not change model weights. Fine-tuning is a separate option when a defined task and an evaluation on held-out examples justify it.

What hardware is needed?

That depends on model size, document formats and volume, concurrent users and acceptable response times. Representative tasks are tested on the intended machine before the installation scope is agreed; the results may call for a workstation or a team server.

Private AI & Workspaces

Which documents and tasks should stay within your control?

Describe the material, the people who need access and the work the prepared system must complete.

Prepare a project brief ↗