← All documentation

AI Systems and Models

The AI system register is where your organization records every use of AI: a tool your staff use, an AI feature inside software you buy, or a system you build. Each system is risk-tiered, reviewed, approved and assessed on its own.

Systems and models are separate

  • An AI system is a use of AI in a business context — "Support assistant", "Resume screening". It is what gets reviewed and approved.
  • A model is a versioned artifact a system runs on — a vendor foundation model, a fine-tune, an in-house classifier. One model can back several systems, and one system can use several models, each in a role (primary, fallback, embedding, guardrail).

Record a model's versions on its page, then link the model to the systems that use it. A system can pin one of those versions, so a change to the model can be traced to every system it affects.

Lifecycle

Every system moves through the same stages:

  1. Proposed — registered, details being completed.
  2. In review — submitted for a decision.
  3. Approved, approved with conditions, or rejected.
  4. Deployed — in use.

A live system can be suspended, sent back for re-review (for example after a material change), or retired. A system in review can also be suspended or retired: its open review is withdrawn, and no decision is recorded. Suspending or retiring always takes a reason, which is recorded in the audit trail and shown in the approval dossier. A system suspended while it was in review never gained an approval, so it goes back through review rather than being reinstated. A rejected system can be resubmitted, and a retired one brought back as a proposal.

Anyone who can edit a system — an organization administrator, its owners, or whoever proposed it — can submit it for review. Approving, rejecting and sending back for re-review are decided inside that review by the approvers its policy names (see AI approvals). The other moves — deploying, suspending, retiring, resubmitting a rejected system and bringing a retired one back — are made by an organization administrator. Every move is written to the audit trail.

A rejected or retired system is not assessed, and has no access review; bring it back as a proposal first. Once an assessment is completed, the set of questions it asked is fixed, so a later change to the system (for example clearing "Uses generative AI") does not change a finished assessment or its score.

Classification

  • Risk tier — your internal tier: unclassified, low, moderate or high.
  • EU AI Act classification — recorded as your organization determined it, with counsel where needed. Backsplice never sets it and does not decide whether a law applies to you.
  • Your roles under the EU AI Act — tick every role that holds for this system. An organization that builds a system and uses it itself is both its provider and its deployer. When the EU AI Act pack is available, the questions for each role you tick are asked. Leave all unticked until the roles are determined.
  • Annex I Section — for a system classed high-risk under Annex I, whether its product legislation is in Section A or Section B. For a Section B product, only Article 6(1), Article 60a and Articles 102 to 112 apply (Article 2(2), as amended), so the Article 73 reporting deadline is not applied. Left blank, Section A is assumed.
  • Decisions it is used for and US jurisdictions its decisions reach — tick the areas where the system's output helps decide something about a person, and where those people live or apply. Together they decide which US jurisdiction question sets apply. One system has to hold both: New York City and Employment bring in the NYC Local Law 144 questions once that set is published.
  • Uses generative AI — set by a person. It decides whether the system's assessment includes the NIST AI 600-1 (Generative AI Profile) questions. A linked model marked generative only suggests it.

Watney's suggestion

On an existing system, Suggest a tier with Watney reads the record and suggests a risk tier and an EU AI Act classification, with its reasoning and the criteria it applied (the criteria are shown on the page). It also lists what the record leaves open. The suggestion is never saved: Put these in the fields below only fills the two fields, and the tier is set when you save the system. For the EU AI Act, Watney names the question the facts point to; whether the Act applies is for your organization to settle, with counsel where needed. The categories can overlap (a high-risk system can also carry Article 50 transparency duties), and where an Annex III use case matches, Watney lists the Article 6(3) exception as a question to settle rather than applying it. A record that is silent on a question is suggested as not assessed, never as none of the listed categories. Only the people who can edit the system see the button.

Bias audits

A system recorded as used for employment decisions has a Bias audits panel. In New York City, Local Law 144 makes it unlawful for an employer or employment agency to use an automated employment decision tool to screen a candidate or employee for an employment decision unless the tool "has been the subject of a bias audit conducted no more than one year prior to the use of such tool" and a summary of the latest audit's results, with the tool's distribution date, is published on its website before use (Admin. Code § 20-871(a)); § 20-871(b) also requires notices. The DCWP rule (6 RCNY §§ 5-300 to 5-304) sets out how the audit is done and what is published. Whether the law applies is for your organization to settle.

Record each audit with its date, the independent auditor, the method (selection or scoring rates), the data used, the categories calculated, and where the summary is published. The next audit is due a year after the latest one. An audit on 29 February falls due on 28 February. The panel shows whether the audit is current, due within 30 days, or overdue. It also lists what the latest record leaves out in the rule's terms: independence not recorded, a category not calculated, test data without an explanation, no published summary, no distribution date, or no count of people in an unknown category.

The system's owners are reminded once when the next audit is 30 days away, and once when it is overdue. Backsplice records the audit. It does not judge the audit's findings: the law sets no pass mark for an impact ratio. Whether the law applies to a system is for your organization to settle, and this is not legal advice.

Monitoring

A deployed system can report its own measurements, so a re-review cites data rather than an attestation. On the system page, its owners, whoever proposed it, or an organization administrator define each metric under Monitoring: a key the pipeline sends (for example accuracy), whether higher or lower is better, and optional warning and breach thresholds. The pipeline then posts points to POST /api/v1/metrics with a key carrying the monitoring:write scope.

The panel shows each metric's latest value, a trend and its state. A value AT a threshold is still within it. When a metric's latest value moves past its breach threshold, the system's owners are notified (its organization administrators if it has no owner) and webhook subscribers receive metric.threshold_breached, once per crossing. Nothing else happens on its own: the system's tier, stage and approval stay as they are, and no incident is opened. An administrator is offered Open an incident, pre-filled as performance degradation, to submit if it needs one. The approval screen shows each metric's latest value to the approvers.

Removing a metric keeps the points already recorded. Points are kept for two years.

The transparency page

An organization administrator can list a system on the organization's public transparency page (turned on under Settings → Transparency page). The page shows the system's latest published system card, never a draft, with its version number and date; it does not show who published it. A system can be listed only once its card has a published version. Removing a system from the page takes effect at once. Listing and removing are recorded in the audit trail. The transparency page comes with a plan; it is not in the demo.

How many systems your plan includes

Premium includes a set number of AI systems, with more available as an add-on; Enterprise has no limit. There is no limit on assessments, program or system. Every system counts toward the AI system limit except one that is rejected, suspended or retired — a proposed system counts. Bringing a suspended or retired system back uses a slot again, so the register tells you when you are at the limit and what frees one: retire or suspend a system, or add more from your billing page.