Governance policies

Every AI request PIES Studio makes — building a screen, writing a function, answering in the chat — passes through your organisation's AI governance policies first. A policy decides which model answers, which providers may be used, whether personal data is masked, and whether the request is allowed at all. Every call is audited. Governance is an Enterprise feature; administrators find it under PIES AI › Governance.

The Governance page

AI Governance has six tabs:

Overview — calls, models and providers at a glance.
Policies — the policies of your organisation, in the order they are checked.
Templates — ready-made policies and policy packs to add or to start from.
Test Console — try a request against your policies and see which one answers.
Access — who may read and change governance (the Governance roles, such as Policy Reader).
Models — the models PIES AI serves, with their cards.

Someone without a Governance role sees AI Governance needs a Governance role instead of the tabs.

How a request finds its policy

Policies are evaluated in priority order, lowest number first, and the first match wins. Drag a row on Policies, or use its arrows, to change the order. A disabled policy is skipped.

A policy matches a request on up to five dimensions. A dimension left empty matches anything. Within a dimension any value may match (OR); across dimensions all must match (AND).

Match on	Values
Classifications	`public`, `internal`, `restricted`, `pci`, `phi`, `pii` — the data classes detected in the request
Request types	`screen`, `function`, `event`, `data_model`, `chat`, `fix`, `app`
User roles	role names, comma-separated
Apps	applications in the organisation, picked by name
Regions	region codes, comma-separated

A request is checked against every class detected in it, so a card number inside an application classified as personal data still meets the PCI rules.

What a policy does

The Mode decides the outcome:

Allow — the request goes ahead, under the settings below.
Deny — the request is refused with the Reason / message shown on deny.
Require approval — the request waits for approval.

An allowing policy also sets:

Allowed providers — the providers the request may go to: Anthropic, OpenAI, xAI, Azure and PIES (your private models).
Preferred model — the model that answers. Only models from the ticked providers can be picked; the others are greyed out with a hint to tick their provider.
A model for heavy work — app builds and redesigns — where the policy names one.
Fallback model (optional) — used when the preferred model cannot answer.
Redaction mode — None — pass through, Mask PII with [REDACTED:type], Strip sentences containing PII, or Reject request if PII detected.
Max tokens and Temperature ceiling — 0 keeps the default.

Reading the Policies list

Each row shows the policy's name, its order, whether it is enabled, and a description that says what it does. Unless you wrote your own, the description is built from the policy's settings, for example Requests matching screen goes to Claude Sonnet; app builds and redesigns to Claude Opus; fallback gpt-5.4; allowed providers: anthropic, azure. A description you write yourself is kept.

An enabled policy that has had calls also shows where they actually went — Resolved: provider / model (N of last M calls) — with one sentence saying why, such as which provider answered or why the preferred model was skipped (its provider is not allowed, has no key, or is not served). The line is highlighted when it differs from the preferred model.

The linter above the list checks every policy; a problem it finds is listed in that policy's row with a Fix link that opens the editor.

Each row has Test this policy, Edit policy and Delete policy. Policies can be exported and restored as a YAML file.

Policies for one application

Pick an application under Apps to make a policy apply only to it, for example to send one application's builds to a cloud model while the rest of the organisation stays on private models. When an application has its own matching policy, Build with AI uses it to choose the model for every unit of that application's build.

Testing a policy

The Test Console takes a request — the prompt, and optionally the user, their roles, the application and the region — and shows which policy answered, its decision and reason, the provider and model chosen, and what redaction did. Test this policy on a row opens the console with that policy ready.