Governance overview
Governance in FYAI answers three questions an auditor, a regulator or your own risk team will ask about the AI you run:
- What do you run, and how risky is it? Every agent, team and function carries a risk classification. Agents and teams can be grouped into registered AI systems with a stated purpose, an owner and a lifecycle.
- What stops it doing harm? At runtime the policy engine decides, for every tool an agent is given, whether the call is allowed, needs a person to approve it, or is denied.
- Can you prove it? The platform records those decisions, maps them to controls in the NIST AI RMF and ISO/IEC 42001 frameworks, raises alerts when a control doesn't hold, and exports everything as an assurance pack you hand to your auditor.
Everything sits under Governance in the left navigation: AI Systems, Review Queue, Policy, Alerts, Control Library and Assurance Pack. All governance data is scoped to your current project.
The model, end to end
Build Classify Enforce (runtime) Evidence
───── ──────── ───────────────── ────────
Functions ─┐ Platform proposes a Policy engine decides per Decision trail (Policy)
Agents ───┼──────────▶ risk level from what ──▶ tool: allow / approval ───▶ Oversight records
Teams ───┘ the object can do required / deny Alerts
│ (Proposed) using risk level, pins, Control Library status
│ │ risk appetite Change history (hash-chained)
▼ ▼ │
AI Systems Person confirms it ▼
(purpose, owner, in the Review Queue Assurance Pack
lifecycle, impact (Reviewed) (JSON export for your auditor)
assessment)
1. Classification
Every agent, team and function has a risk level: Critical, High, Medium, Low or Informational. When you create one, the platform proposes a level from what it can actually do — a function that spawns a subprocess is High, a built-in is Informational, an agent inherits the highest level of its tools, a team the highest level of its agents. A proposed level is not a decision: it shows as Proposed until a person confirms it in the Review Queue or with Mark as Reviewed on the object's Risk tab. See Risk classification.
2. AI systems
An AI system is the governance unit above agents and teams — what you'd list in an inventory of "AI we operate". It records an intended use, declared misuse, an owner, and a lifecycle state (Draft, In Development, Live, Deprecated, Retired). Its risk tier is the highest level of the agents and teams inside it. A High or Critical system can't go Live without a named owner and a current, independently approved impact assessment. See AI systems and impact assessments.
3. Runtime enforcement
When an agent is built for a chat or workflow run, the policy engine decides each tool's posture:
- Denied — for example the tool's MCP server is killed or quarantined, its advertised tools changed and nobody reviewed the change, or a built-in tool is disabled for your organisation.
- Approval required — a person must approve each call. This happens when the tool's risk is at or above your risk appetite threshold (High and above by default), when the tool is unclassified, when someone pinned it to Always require, and always for Critical risk unless the appetite is Bypass all.
- Allowed — everything else.
High- and Critical-risk tools are also marked so they won't run once untrusted content has entered the conversation. See Approvals and risk appetite.
4. Evidence
| Evidence | Where you see it |
|---|---|
| Every policy decision, its reason code and the policy version it was decided against | Policy → Decisions |
| Whether a second decision path would have agreed (shadow comparison) | Policy → Divergence |
| Results of the conformance suite trying to get past each control | Policy → Conformance |
| Findings the platform raised, and whether anyone was notified | Alerts |
| Whether each NIST AI RMF / ISO 42001 control is operating, computed from the above | Control Library, and the Controls tab on each agent, team and function |
| Test-case results for an AI system's agents and teams | AI Systems → Evaluation |
| Who approved or rejected a tool call | Oversight records (API) and the approval itself in chat |
| Change history of every governed object, hash-chained so tampering is detectable | Each object's History tab, and the assurance pack's audit trail |
5. The assurance pack
The Assurance Pack pulls all of this into one point-in-time record of the project's governance position, including a list of gaps (unreviewed objects, systems with no owner, models whose data-training stance is unknown, failing conformance cases, controls nothing evidences) and whether the hash chains behind the record verify. You export it as JSON. See Assurance pack.
Who can see and do what
FYAI project roles, from least to most access, are Runner, Viewer, Editor and Admin. Organisation Owners and Admins count as project Admin in every project of their organisation. Runners can't read governance data.
| Screen | Who can see it | Who can act |
|---|---|---|
| AI Systems | Viewer and above | Editor and above: register and edit systems, attach agents and teams, move lifecycle state, start and approve impact assessments (you can't approve an assessment you wrote) |
| Review Queue | Viewer and above | Editor and above: Accept proposals |
| Policy (Decisions, Divergence, Conformance) | Viewer and above | Read-only |
| Alerts | Viewer and above | Editor and above: Acknowledge, Resolve. Admin: install the default alert rules |
| Control Library | Viewer and above | Admin: load the shipped catalogues, bind control profiles, add and edit entity bindings |
| Assurance Pack | Admin only — hidden from the menu for everyone else | Admin: view and export |
| Risk tab on an agent, team, function or integration | Anyone who can open the object | Editor and above: Update, Mark as Reviewed |
| Settings → Risk Appetite (project) | Admin only | Admin |
| Settings → Account → Risk Appetite (personal) | Everyone | Everyone, within the limits your organisation allows |
Buttons on some governance screens are shown to every role, but the platform refuses the action if your role isn't high enough — you'll see an error message rather than a hidden button.
Where to start
- Open Review Queue and accept (or correct) the proposed risk levels for your agents, teams and functions.
- Check your project's risk appetite under Settings → Risk Appetite.
- Register your AI systems under AI Systems, attach their agents and teams, and complete an impact assessment for anything High or Critical.
- In Control Library, load the shipped catalogues so control status can be computed.
- In Alerts, install the default rules if the page says none are configured.
- When an auditor asks, generate the Assurance Pack.
In this section
- Risk classification — levels, how they're proposed, the Risk tab
- Review Queue — confirming proposed levels
- Approvals and risk appetite — what the policy engine enforces at runtime
- AI systems and impact assessments
- Policy — the decision trail, divergence and conformance
- Reason codes — every reason a decision can carry
- Alerts
- Control Library
- Assurance pack
- Governance API — oversight records, attestations, model governance and other API-only features