DocumentationGovernance Center
Compliance rules
On the Compliance page of the anymize Governance Center you decide what is binding when using AI: forced anonymization, allowed models and connectors, retention and locked features.
6 Min
What compliance rules are for
A firm buys anymize because of anonymization. That helps little if it is a switch anyone can turn off. Here you make it binding: from the moment “Enforce document anonymization” is on, every uploaded contract is anonymized automatically. The client name becomes a placeholder before anything reaches an AI model, and nobody in the firm can bypass that.
The same page carries three more kinds of rules: which models and connectors are allowed, how long the mapping from placeholder to clear name is retained, and which features are turned off for your firm. Every rule has a default “For everyone” and any number of per-group exceptions.
Click a rule and it expands. At the top is the default; underneath you add an exception with “Add group”. A new group exception starts as a copy of what is currently above, so you tighten or loosen from there instead of landing on the factory default.
Anonymization rules
Four rules, all effective without a team as well, because they protect your own data. By default only the last one is on.
| Setting | What it does | Team plan only |
|---|---|---|
| Enforce document anonymization | Every uploaded document is anonymized automatically, without exception. | no |
| Require manual document review | Documents must be reviewed and confirmed before send. | no |
| Enforce prompt anonymization | Typed messages are anonymized automatically too, not only attachments. | no |
| Enforce review before send | The anonymized message appears for review before send; you send it. On by default. | no |
Access: models and connectors
Two allow-lists. Both know only two states: everything allowed, or exclusively what is ticked.
| Setting | What it does | Team plan only |
|---|---|---|
| Model access | Which AI models may be used. Quick picks: “anymize only” and “EU only”. | no |
| Connector access | Which connectors may be used, for example only Microsoft 365 and Nextcloud. | no |
For models an empty selection counts as “all allowed”. That guards against locking yourself out, because an account with no model at all could no longer work. So pick at least one.
Features you can turn off
Sixteen rules, all on the Team plan. They share one trait: they take a feature away from other people. Someone working alone would only forbid themselves something and could flip the switch back anytime, so they only apply with a team.
| Setting | What it does | Team plan only |
|---|---|---|
| Disable web search | Web search in chat is unavailable; no chat content goes to a search provider. | yes |
| Disable Intensive Research | Intensive web research is off; normal web search can stay. | yes |
| Disable fetch web pages | Individual web pages cannot be loaded into chat or added to a knowledge base by URL. | yes |
| Forbid custom models | Members may not connect personal AI models. Models the team provides stay allowed. | yes |
| Forbid custom connectors | Members may not create their own connectors with arbitrary server addresses. Team connectors stay allowed. | yes |
| Forbid public chat links | No more publicly shareable links to chats can be created. | yes |
| Limit chat invitations to the team | Chats may only go to active team members, not to external addresses. | yes |
| Disable API keys | Members cannot create new API keys. Existing ones keep working. | yes |
| Block API access | The public API no longer responds; existing keys stop working too. Running integrations break. | yes |
| Block developer console | The developer console is no longer reachable for members. The API itself is unaffected. | yes |
| Disable code execution | The assistant cannot start a sandbox, run commands or install packages. Live previews of generated web apps also go away. | yes |
| Lock team dictionary | This group works only with its own dictionary entries; the shared one is neither read nor extended. | yes |
| disable_agent_channels | Removes channel connections from agents - Telegram, Slack, Teams and Discord. Existing channels pause; new ones cannot be created. | yes |
| disable_restore_consent | Turns off the confirmation otherwise asked before someone resets another person's work. Off by default, so the question is asked. | yes |
| agent_max_autonomy | Caps how autonomously an agent may run in the workspace, from “plan only” to “without asking”. | yes |
| Max. API key validity | Forces an expiry date for new API keys, for example 90 days. No forever-valid keys anymore. | yes |
Three rules still show their technical name in the UI instead of a localized label: disable_agent_channels, disable_restore_consent and agent_max_autonomy. You recognise them in the list by exactly that spelling. For capping agent autonomy the matching control is also still missing, so do not rely on it yet.
Retention and knowledge bases
| Setting | What it does | Team plan only |
|---|---|---|
| Mapping retention | How long anymize remembers which placeholder stands for which real value. Choices from “Delete immediately” via 5 minutes, 3 hours, 1 day and 1 month up to 6 months or “Unlimited”. | no |
When the period expires the anonymized text stays readable; only the path back to the clear name is closed. A solo account sets this value directly under “Privacy settings”; a team uses the rule above, optionally per group.
The three knowledge-base rules deliberately do not live here but on their own page in the Governance Center. Otherwise the same rule would have two switches in two places, and flipping one would not visibly move the other.
Can I turn off web search for my team?
Yes, with “Disable web search”. That is one of the most common questions from firms that bought anymize precisely for privacy: anonymization protects the path to the AI model; web search would be a second path outwards.
When the rule is on, the model is not even offered the tool. It cannot try search in secret; it simply says it cannot look things up online. If you want search results but not whole pages, leave web search on and instead turn on “Disable fetch web pages” and “Disable Intensive Research”.
What an employee notices when a rule applies
As little as possible, and never a cryptic error message. The rule acts where the feature would otherwise be.
- Anonymization enforced: the menu item for upload without anonymization is simply gone, and an image without anonymization is rejected.
- Model blocked: the model is not in the chat picker. No notice, no error - it is simply not there.
- Web search, research or page fetch blocked: the model lacks the tool and answers honestly that it cannot look things up.
- Public links or external invitations blocked: the attempt is rejected; sharing with colleagues on the team still works.
- API blocked: calls are rejected, even with a valid key.
Anyone on the team without admin rights sees a read-only view on this page: the applicable rules, greyed out, with the note “Set by your team”. Plus the three figures that really affect them: how many models and connectors are allowed and how long mappings are retained.
Who may change things here
| Account | What you see |
|---|---|
| Owner or Admin on the team | All rules, the default “For everyone” and per-group exceptions. Changes land in the audit log. |
| Member on the team | Read-only view of what applies to you. Your admin can change it. |
| Solo account without a team | Anonymization rules, retention and your own model and connector selection. Team-bound rules sit below visibly locked. |
At the very bottom of the page are the data processing agreement and the BRAO consent declaration for download - the same files as in the Documents area.