Skip to content

Enterprise IT

Thorsten Sommer edited this page Oct 30, 2026 · 8 revisions

Do you want to manage MindWork AI Studio for an organization? These pages explain how your IT department configures AI Studio centrally, how the configuration reaches each device, and which settings fit typical needs.

What you can manage

With a central configuration, you can:

  • Roll out providers: LLM, embedding, and transcription providers, self-hosted or in the cloud, with API keys that you encrypt, or with a prompt that asks each user for their personal key.
  • Protect data: set how much AI Studio trusts each provider, require a minimum trust level, decide which providers may see the content of confidential data sources, and prohibit providers altogether.
  • Prepare the work: roll out chat templates, profiles, policies for the Document Analysis Assistant, and data sources on ERI servers.
  • Control tools: switch tools such as web search on or off, configure them, and lock their settings.
  • Distribute assistants: approve and roll out assistant plugins, and hide built-in assistants you don't need.
  • Set defaults or lock settings: for example, the start page, the default provider, the preview features, or what users may import and back up.
  • Control updates: let AI Studio update itself, or distribute approved versions yourself.
  • Label and measure: label AI-generated content, and learn which features of AI Studio send requests to your self-hosted AI servers.

AI Studio checks these settings on every device and applies changes while it runs. Users don't need to restart it.

How it works in brief

  1. You write a configuration plugin: a small Lua file that lists your providers and settings.
  2. You put it into a ZIP file on a configuration server in your intranet, an ordinary web server.
  3. On each device, you store the ID of the configuration and the address of the server, for example, through group policies in the Windows registry or as a policy file on Linux and macOS.
  4. AI Studio downloads the configuration when it starts and checks for changes every 16 minutes.

How Central Configuration Works explains each part in detail.

Pages in this section

Basics

  • How Central Configuration Works: the parts, the IDs, multiple configurations, locked settings and defaults, and withdrawing a configuration.
  • Configuration Server: what your web server must do, and how to trust your organization's own certificate authorities.

Deployment

Configuring

Topics

Scenarios

  • Configuration Scenarios: complete configurations for typical needs, from local models only to cloud providers under contract.

Help

The reference for every setting

The complete list of settings, with an explanation and the allowed values of each, is the example configuration plugin in our repository. The pages here explain the settings by topic and link to it instead of repeating every key.

The example on main may already describe settings of the next release. To see the example of your version, switch GitHub's branch selector to the tag of your release, such as v26.10.1.

Plan for slow rollouts

Organizations often take weeks until every device runs a new version. Whatever you configure with a new version must therefore still work for devices that run an older one. Where a setting needs a certain version, these pages say so.

Questions and requests

Is a setting missing that your organization needs? Open an issue in our planning repository.

Clone this wiki locally