The control tower

When a whole team builds and publishes with AI, someone needs to see the whole picture: what’s live, what collects personal data, what’s exposed to the world. The control tower is that view: one screen over every site your organization has, built by anyone on the team.

Who can open it

The control tower is for organization governance. You’ll see it if you are an owner, an admin, or hold the dedicated governance role in the organization (or if you’re a Bailey super-admin). Members without one of those roles don’t see it.

Two ways in:

• The Control tower entry in the left rail.
• The Open control tower button on the Organization page.

It’s an organization view; your personal space isn’t part of any fleet.

What it shows

Every app owned by the organization, each with three read-outs, all computed on the server from real facts (never guessed):

• Exposure (the blast radius): how reachable the data is (public vs members-only vs owner-only), whether a custom domain points at it, how much has been collected, how sensitive the fields are.
• Risk: a score built from traceable gaps, like personal data without a legal basis, no retention limit, a public form with no notice, personal data collected outside the declaration (a “shadow” tripwire), and more. Each gap is listed with its reason and weight: a score you can explain.
• GDPR posture: none / declared / incomplete / shadow.

A risk × exposure map plots the fleet so the worst offenders stand out, and you can filter by risk tier, GDPR status, or search.

An organization page served in public is a flagged risk

A page owned by the organization but open to the whole web is an exposure in its own right: your organization’s content, reachable outside it. The control tower counts it in the risk score so it surfaces, even when the page holds no personal data. Restrict it to members from the page’s access settings if that wasn’t intended; see Internal pages.

Admin vs governance

• Admins (and owners) run the organization: brand, members, plan, projects.
• Governance is read-only across the organization: it oversees, it doesn’t edit anyone’s pages, brand or data. It has exactly two bounded actions, below.

The two governance actions

Governance can’t rewrite someone’s page; that stays with the page’s creator. What it can do:

Cut a page (kill-switch)

If a page looks dangerous, take it offline in one click. It stops being served immediately (and can be brought back the same way). System pages are protected.

Ask the creator to clarify

Request a clarification on a page, optionally about a specific data bucket, with a short note. This isn’t just logged: the creator is notified, both by email and in the dashboard. The next time they open that project, a banner tells them governance asked for a clarification, with your note. They review the page’s data declaration, fix what’s needed, and mark the request resolved.

Why it works this way

Governance asks; the creator acts on their own page. Oversight stays separated from editing: nobody’s work is silently changed, and the person who knows the page is the one who fixes it.

Inviting a governance reviewer

Give someone the governance role from the Organization page (Members → set role). They’ll get read-only oversight of the whole fleet plus the two actions above, without the ability to administer the organization or edit its pages.