01

Enterprise theatre vs. real accountability

The biggest lie of the last ten years of SaaS selling has been that compliance is a feature list. SOC 2 logo, ISO ribbon, GDPR notice in the footer. For a 500-person buyer that's the entry ticket, but it says nothing about how the product behaves when someone walks into your office on a Tuesday morning and says: “Please delete everything we hold about Mr K., he has objected.” That's where governance splits from theatre.

For mid-market products, governance is not what's in the certificate. It's what is doable by the person at the admin dashboard, without a ticket to the ops team. The rest is paper.

02

Tenants are not a feature flag

Real tenant isolation happens at the datastore layer, not in application code. In ChatFlow every tenant has its own Qdrant collection, its tenant-scoped Mongo records, its tenant-scoped Postgres queries with FK enforcement, its Redis prefix, and its own agent graph cache. There is no code path where tenant A accidentally sees tenant B — not because the team is disciplined, but because the datastore says no.

For superadmins there's god-mode: an X-Tenant-Id header that temporarily pushes the application into another tenant's context. The UI shows an orange banner so nobody ever edits the wrong thing. That's not only security, it's UX — it keeps well-meaning people from saving a persona under the wrong tenant.

03

Roles for teams of 5 to 50

Six roles, ranked, bound to a tenant. A user can be Developer in tenant A and Customer Admin in tenant B — roles are per-tenant.

  • Superadmin (level 100) — platform-wide, billing, tenant creation
  • Platform Admin (90) — platform-wide, no tenant creation
  • Tenant Admin (80) — everything inside one tenant
  • Developer (60) — agents, tools, KBs; no user or persona management
  • Customer Admin (40) — read conversations, run analytics, no config changes
  • Customer User (20) — read only
04

Snapshots: git for configurations

An agent graph is not a file in a repo. It lives in the database, is edited through the admin UI, and the risk that someone saves the wrong persona at 5:30pm on a Friday is real. So we built snapshots as a first-class citizen — not an export feature, but version control.

Two scopes: “Agent Graph” (agents, tools, skills, guardrails, KB bindings, persona, canvas) and “Full Config” (additionally model registry, voice, telephony, web sources). Explicitly not in snapshots: KB documents, conversations, API keys, secrets — those are runtime data, not configuration. Every restore operation automatically creates snapshots before and after. Rollback is three clicks and seconds of wall time.

A platform you can't roll back doesn't have governance — it has hope.

05

Audit log: what's in, what's not

The audit log is intentionally tight. It captures decisions by humans that change configuration: login / login-failed / password-changed, tenant creation, agent updates, adding a handoff, webhook tests, API key creation / rotation / revocation, document uploads, retention cleanups, platform settings changes. Each entry includes IP, user agent, and before/after values.

Explicitly not in the audit log: end-user messages (those are in Conversations, with their own retention), read-only page loads, internal cron jobs. That's a design choice — an audit log that records every interaction is useless. An audit log that records the humans' decisions is a tool. Accordingly, the audit log's retention runs longer than the data it describes — it must outlive what it documents.

06

GDPR without the legal team

The role split is clear: tenant is Data Controller (decides what is collected), platform is Data Processor (executes what the tenant instructs), end user is Data Subject. That split is not optional, it's the law — and it determines who gets which endpoints.

  • GET /memory/contacts/{id}/export — right of access, portable JSON
  • DELETE /end-user/me — right to be forgotten, self-service via cookie auth
  • DELETE /memory/contacts/{id} — erase persisted memory data
  • Per-tenant retention with a daily batch deletion job
  • Starred conversations as an explicit exception (quarterly review)
07

AI Act — the 80% answer

Most chatbot applications sit under Art. 50 “limited risk” (transparency duty: the user must know they're interacting with AI). The 15% that become high-risk (employment decisions, credit scoring, health triage, essential services, law enforcement) need more: risk management, data governance, record keeping, human oversight, accuracy. The platform supplies the tools — guardrails, KB document management, conversation logs, persona disclosure, admin kill switch, regression-testing framework.

What it does not supply is your compliance assessment. That's intentional. Nobody should delegate a compliance decision to a SaaS platform that doesn't know the product. The platform gives you the building blocks — the assessment of whether your use case is high-risk is yours (or your lawyer's).

08

What we don't fake

Governance is less a marketing chapter and more a stance. The platform does what it does, openly and documented. It has an audit trail for configuration changes, snapshots for rollback, roles that make sense, endpoints for data subjects, and an honest description of what data leaves the EU. That's not compliance magic, it's product hygiene.

The rest — legal assessment, certifications for specific industries, audits — belongs with the customer and their experts. We're the platform. We package responsibility so that it remains transportable.