Private betaRequest early access →

Sign in

AI system inventory and impact assessments

Zynth keeps two registers for every AI agent your organization runs: an inventory profile that says what the agent is and who answers for it, and impact assessments that record its risks and the decision to run it, signed off by a second person. Together they are the evidence an EU AI Act deployer (Articles 9, 26 and 27) or an ISO/IEC 42001 auditor (clauses 6.1 and 8.2) asks to see first.

Zynth records, governs and audits these judgements. It does not make them: the platform runs no model of its own, so whether a use is fair or safe is your organization's call, and the register makes sure that call is written down, signed by two people, reviewed on time and still describes the agent you are running.

Who can do what

PermissionWhat it allowsHeld by
aigov:readRead profiles, assessments, coverage and the exportAdministrator, Compliance Officer, Security Operator; Auditor through read-only access
aigov:writeWrite a profile; draft, submit and withdraw an assessmentAdministrator, Compliance Officer
aigov:approveApprove or reject a submitted assessmentAdministrator, Compliance Officer

Writing and deciding are for people only. An agent's token is refused, whatever it holds: an agent never describes or signs off itself or another agent. The Compliance Officer can also see the agents (agents:read) it governs. The registers are available on every plan.

The inventory profile

One per agent, written whole with PUT /api/v1/aigov/profiles/{agent_id}:

  • Owners: a business owner (required) and a technical owner, each an active member. Whoever holds aigov:write can list the people a record may name with GET /api/v1/aigov/owners (an id and a name, or the email when there is no name), so keeping the registers does not need the member list's permission.
  • Purpose: what the agent is for, its intended use, and the uses that are out of scope.
  • Context: internal, customer-facing or public; whether it interacts with people; whether it affects decisions about people.
  • Model: provider, name and version.
  • Data: the data categories, and whether it processes personal or special-category data.

Each change is recorded with the fields that moved, from what to what.

Impact assessments

An assessment belongs to one agent and is versioned. It records:

  • the classification (prohibited, high_risk, limited, minimal or gpai), the EU AI Act Annex III area if any, and your role (provider, deployer or both);
  • the purpose, intended use, affected persons, human-oversight measures and data governance;
  • a fairness review (method, attributes considered, findings, outcome, evidence), required before submission whenever the assessment names affected persons or an Annex III area;
  • each identified risk, scored 1 to 5 for likelihood and severity, its mitigation, the residual score and an owner;
  • the residual risk and the decision: accept, accept_with_conditions (with the conditions stated) or reject;
  • links to the evidence you keep elsewhere (an https:// or urn: address, optionally with its SHA-256).

Lifecycle

  1. Draft. Only the author edits a draft (PUT /api/v1/aigov/assessments/{id} replaces it).
  2. Submit. The author submits; the record is then frozen.
  3. Decide. A different person approves or rejects. The author is refused (403), and the attempt is recorded and raised as a detection. A rejection needs a reason.
  4. Withdraw. The author may withdraw a draft or a submitted assessment, with a reason.

Approved and rejected assessments never change. A newer approved version supersedes the previous one, which stays in the register as the record of what was decided then.

Two rules the register enforces:

  • A prohibited practice is never accepted. An assessment classified prohibited can only carry the decision reject; anything else is refused (422). Every submission or decision on one is recorded at critical severity and raised as a critical detection.
  • An unacceptable residual risk is never accepted.

Review dates and staleness

Approval records the agent's governance band (risk level, oversight mode, risk ceiling, confidence floor) and sets the review date: 180 days for high-risk, 365 for limited and general-purpose, 730 for minimal. Zynth checks every approved assessment each hour and raises a detection when:

  • the review date has passed, or
  • the agent's band no longer matches what was approved (it was tightened or loosened since).

Either way the agent keeps running; draft and approve a new version.

Coverage

GET /api/v1/aigov/coverage lists every agent with whether it has a profile, its current approved assessment and classification, its review date, and whether it is overdue or stale. An agent counts as covered when it has a profile and a current, in-date assessment.

Export

GET /api/v1/aigov/export/assessments returns every version of every assessment (or one agent's, with agent_id), with their risks and decisions, up to 5 000; truncated says when there were more.

What is recorded

Every write and decision is in the tamper-evident audit log and mapped to the controls it evidences (EU AI Act Art 9, 14, 26 and 27; ISO/IEC 42001 6.1, 8.2 and 9.1). Reads are recorded too.

In the console

AI Governance → AI-system inventory lists every agent with the state of its governance file and opens its profile. Impact assessments lists every version, filters by agent and status, and exports the register; an assessment's page shows its risks, fairness review and band at sign-off, and offers only the acts you may take: the author edits, submits or withdraws, and someone else approves or rejects.