← All documentation

Systems and AI models

Systems is where your organization records each system it builds, buys or uses, once: a tool your staff use, software you buy, an AI feature inside it, or a system you build. Add one with Add system.

The two flags

Every system carries two flags, and the form asks each as a question: Yes, No or Not sure, with nothing chosen for you. At least one is yes; an electronic health record with an AI scribe is one system with both. Not sure is treated as yes until you answer (the system is asked those questions and counts toward that limit), and the system's page asks you to confirm it.

  • Uses AI — the system uses, contains or is an AI system. A system with this flag is risk-tiered, reviewed, approved and assessed on its own, and the AI fields, sections and questions below follow it.
  • Handles ePHI — the system creates, receives, maintains or transmits electronic protected health information. HIPAA questions about a single system are asked only of a system with this flag, the limit on systems that handle ePHI follows it, and your security risk analysis starts its scope from it. Until you record whether the vendor you link to it handles PHI, that vendor is listed as a possible business associate to confirm, unless the system is retired or rejected or the vendor is terminated.

A system without Uses AI has no review or approval. Its status is In use or Retired: it is in use from the day it is added, an organization administrator can retire it (with a reason) or put it back in use, and an AI governance assessment is not started for it, because it would ask nothing.

Turning Uses AI on for a system in use opens its first review at once, with the approvers its policy names; the system stays in use while they decide, and if they reject it, it is suspended. If no one can approve it yet, the change is refused and nothing is saved. That first review cannot be withdrawn, and the system cannot be suspended, retired or sent back while it runs: its approvers approve it or reject it. Turning Uses AI off is refused while a review is open (withdraw it first, or let its approvers decide) and for a suspended system (reinstate or retire it first); it ends the system's review and approval, and the system becomes In use, or Retired if it was rejected or retired. When that would put a proposed or approved system in use, only an organization administrator can do it, and not while a condition of its approval is still open. Turning a flag off never deletes anything: the system's reviews, models, datasets, impact assessments and other AI records are kept behind one section on its page, and come back when the flag does.

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.
  • An AI 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.

An organization administrator can also act on several systems at once from the register: tick them, then pick a system owner in the bar that appears and apply it, or export just the ticked systems. Each system is changed as it would be on its own page, so a system whose record that save would refuse is left as it was and named with the reason.

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. The questions for each role you tick are asked in an assessment that selects the EU AI Act pack. 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 in an assessment that selects the EU AI Act pack the system is asked only the Article 6(1) classification question, and the Article 73 reporting deadline is not applied. The general-purpose AI model questions are not limited by this, because Chapter V binds the provider of the model, not the system. 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, work or apply. Together they decide which US jurisdiction question sets reach the system in an assessment that selects them. One system has to hold both: New York City and Employment bring in the questions of NYC Local Law 144 of 2021 (AEDT) where an assessment selects that pack.
  • Uses generative AI — set by a person. It decides whether the system's assessments include the NIST AI 600-1 (Generative AI Profile) questions, and the Singapore Model AI Governance Framework for Generative AI (2024), Singapore Model AI Governance Framework for Agentic AI (v1.5, 2026) and OWASP Top 10 for LLM Applications 2026 questions where an assessment selects those packs. A linked model marked generative only suggests it.
  • Built on a general-purpose AI model (EU AI Act) — set by a person, and a fact about the system: the EU AI Act defines a general-purpose AI model in Article 3(63), and in Article 3(66) a general-purpose AI system as "an AI system which is based on a general-purpose AI model and which has the capability to serve a variety of purposes, both for direct use as well as for integration in other AI systems". Ticking the box records only that the system is built on a general-purpose AI model, not that it is a general-purpose AI system. With a link to the EU recorded, it brings in the questions of EU AI Act GPAI model obligations (Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744) on the models a system is built on in an assessment that selects that pack (the pack's question on whether your organization provides a general-purpose AI model is asked, whether or not the box is ticked, in a program assessment that selects it while any system in your inventory, other than a rejected or retired one, has a link to the EU recorded), and its questions for providers of general-purpose AI models are asked there when the system is also placed on the market or put into service in the EU, unless you record that your organization is not the provider of the model. When a linked model's card records that model as a general-purpose AI model and this box is not ticked, the system page says so and names the model. Neither record is changed for you: check which is right and correct it.

What the question sets need to know

A few more facts decide which questions of the packs an assessment selects reach this system, so that a question set is not asked of systems it was not written for. Each hint on the page names the question sets the fact changes, marking any still under review. Leave a fact as not recorded until it is determined: a fact that is not recorded keeps the questions that need it, and recording No (or leaving a role unticked once another is ticked) is what removes them.

  • Sourcing (with the overview fields) — Built in-house covers a system your organization designs, develops, trains or fine-tunes (including through a provider's fine-tuning service), including an application it builds on a provider's model. A system recorded as a vendor AI product or an **AI feature inside other software** is one your organization uses as supplied, so its assessments do not ask the questions some packs write only for whoever designs, trains or develops the model (the hint beside the field names those packs). Other questions about developing AI follow the organization's own answers and are still asked. Left as not recorded, those questions are asked.
  • Uses predictive AI and An AI agent — yes, no or not recorded.
  • Provider of the general-purpose AI model itself — read only with the box above ticked and "Placed on the market or put into service in the EU" recorded as its link to the EU. The Act's recital 97 says a general-purpose AI model may be placed on the market in various ways, including through APIs, libraries, direct download or a physical copy.
  • Article 50 functions — the EU AI Act's transparency duties attach to what the system does, whatever its classification, except that Article 2(2) does not apply them to a high-risk system under Annex I, Section B. Left blank, the Article 50 questions are asked in an assessment that selects the EU AI Act pack; record the functions, or None of these, to narrow them.
  • Relies on the Article 6(3) derogation — tick it if, as provider, your organization has concluded under Article 6(3) that this system, though referred to in Annex III, is not high-risk. Only a ticked box asks the documentation and registration questions, in an assessment that selects the EU AI Act pack.
  • US state-law role and UK Code role — tick every role that holds. Left blank, every role's questions are asked in an assessment that selects their pack; record the roles, or None of these, to narrow them.
  • CCPA regulations § 7150(b)(4)–(6) processing — with California ticked, any of these brings in the California questions even with no decision domain, in an assessment that selects that pack.

One system has to hold a fact together with everything else a question needs (its role, its classification, the jurisdiction): the program assessment asks an organization-level question of a pack it selects while any one live system holds all of it. A program with no live AI system in the registry holds none of these facts, so its assessment asks no question that needs one until a system is recorded.

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 an optional warning threshold and action threshold (warn_threshold and breach_threshold in the API). 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: Within threshold, Warning or Past action threshold (ok, warn and breach in the API). A value AT a threshold is still within it. When a metric's latest value moves past its action 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. A person decides what to do about it. An administrator is offered Open an incident, pre-filled as performance degradation with the metric, the value and when it was measured; the incident records that reading and links back to the metric. The system's owners, whoever proposed it, or an administrator can Request a re-review of an approved or deployed system: it opens a re-review through the same path as an expired approval, its approvers are notified, and the system keeps its stage until they decide. The approval screen shows each metric's latest value to the approvers.

A deployed system recorded as high-risk with no published monitoring plan is flagged on the panel, so the gap is visible. That is a gap in the record, not a legal conclusion.

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

Human oversight

The Human oversight panel lists who is assigned to oversee the system and what each person can do:

  • Monitor its operation: understands what the system can and cannot do, watches how it runs, and spots anomalies, failures and unexpected performance.
  • Interpret its output: reads the system's output correctly.
  • Disregard, override or reverse its output: can decide not to use the output in a particular case, or override it.
  • Stop or interrupt it: can intervene, or stop the system through a stop procedure that leaves it in a safe state.
  • Escalation contact: the person concerns about the system are raised with.

These follow the list in EU AI Act Article 14(4) of what people assigned human oversight of a high-risk system are to be enabled to do. Article 26(2) says deployers "shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support", so each assignment can record the person's authority to act and their competence and training. For a person who interprets or overrides the output, record the date they were briefed on automation bias: made aware of the tendency to rely, or over-rely, on the system's output, and how to guard against it. That is good practice for any system, and Article 14(4)(b) describes it for the people who oversee a high-risk system. The date can be given when the person is added, or recorded later with Record briefing beside the assignment; the panel flags a current interpreter or overrider without one. Recording an assignment here is not a finding that a system's oversight meets the Act; whether the Act applies is for your organization to settle, and this is not legal advice.

The system's owners, whoever proposed it, or an organization administrator add people and end assignments. Only an active member who is not an auditor can be added. Ending an assignment keeps it in the roster history with its dates and reason. Removing someone from the organization ends every assignment they hold. A person who is suspended stays listed but is marked as no longer able to act, and is not counted.

When a high-risk system has nobody current who can override its output or stop it, the panel says so, and so does the approval screen. That is a note for the approvers; it does not block an approval.

Record a roster review stamps the date and who confirmed the roster. The compliance calendar's Human-oversight roster review activity lists the systems approved for use or in use that have nobody on the roster, the high-risk ones with nobody who can step in, those with someone who interprets or overrides the output and no automation-bias briefing recorded, and those whose roster review is due on the activity's cadence. Its reminder email says the same: the member assigned the activity, or the organization's admins when nobody is, is told which systems; an outside helper or an auditor assigned the activity is told how many. The approval dossier includes the roster as of the day it is generated, with its history and last review. Download your organization's oversight roster (CSV) exports every assignment on every system.

Monitoring plan

The Monitoring plan panel holds a plan for how the system is watched once it is running: what is monitored and why, the data sources, the defined metrics it relies on, how often the plan is reviewed, who is responsible, the thresholds and how a crossing is escalated, and how findings reach the incident register and a re-review. A plan can name a metric before it is defined; the panel says which are not defined yet.

When AI is available to your organization, Draft the empty fields with Watney drafts every field you have not written yet, from the system's record, its defined metrics and thresholds, and how many people hold its oversight roles (no one is named to the model: where the plan needs a name it writes a placeholder). It never writes over a field you have filled in, and nothing is saved until you save the draft.

Write the draft, then Save and publish. Each published version is frozen with the metric definitions it names and the oversight roster as it then stood, and cannot be changed afterwards; edit the draft to start the next version. Record that the plan was reviewed confirms the published version is still current; the panel shows when the next review is due. The approval dossier includes the latest published version.

Article 72(3) of the EU AI Act says "The post-market monitoring system shall be based on a post-market monitoring plan." That article is about providers of high-risk AI systems. For deployers, Article 26(5) says deployers "shall monitor the operation of the high-risk AI system on the basis of the instructions for use and, where relevant, inform providers in accordance with Article 72". Whether either applies to your organization, and whether a plan recorded here meets it, is for your organization to settle; this is not legal advice.

EU AI Act registration and documentation

The registry entry records when the system was placed on the market and put into service, and its EU database registration reference and date, as your organization knows them. The EU AI Act registration and documentation panel states when no registration is recorded for a system recorded as high-risk under Annex III (a statement about your records, not a legal conclusion), and downloads the technical documentation package (Annex IV), which lists every point of Annex IV with what the system's records hold for it. See EU AI Act regulator documents.

Under Instructions for use the entry also records the instructions for use of a high-risk system (Article 13): the document as you name it (its title, file name or where it is kept), its version and its date. A deployer uses the system in line with them (Article 26(1)); a provider draws them up, and the technical documentation package lists them under point 1(h). A version or a date needs the document beside it. Whether the instructions meet Article 13 is for the questions that ask it, not this record.

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 paid plan; it is not on the Free plan.

Export and import

An organization administrator or an auditor with access to the register can export it as CSV or as an Excel workbook from the register page. The file holds the systems the page is showing, with its search, stage, tier and generative filters applied, and each row carries the registry fields: purpose, owners (names only), business unit, sourcing, vendor, deployment context, autonomy, risk tier, EU AI Act classification and role, the flags, lifecycle stage, next review date, the latest AI governance system assessment's score and how many models are linked. Every export is recorded in the audit trail. Exports come with a paid plan; they are not on the Free plan.

An organization administrator can import systems from a CSV file with the Import CSV panel. Download the template for the columns it reads; every row is previewed before anything is written. Two optional columns set the flags, uses_ai (yes by default) and handles_ephi (no by default), each yes or no (a blank cell takes the default, and any other value refuses the row). A blank sourcing cell leaves the sourcing not recorded; a row whose system uses AI starts as proposed, and one that does not starts in use. Either way the system counts toward the limit of each flag it holds, so a row past a limit is refused and named in the preview. Shortly after an import you can undo it as a whole. The panel is not offered while every system limit of your plan is reached, or before the data processing agreement is accepted.

How many systems your plan includes

Each flag has its own limit: one for systems that use AI and one for systems that handle ePHI. A system with both flags counts toward both. Premium includes a set number of each; more systems that use AI are available as an add-on, and more systems that handle ePHI are arranged with us (that add-on cannot be bought from the billing page yet). Enterprise has no limit on either. There is no limit on assessments, program or system. Every system counts toward the limit of each flag it holds except one that is rejected, suspended or retired — a proposed system counts. Turning a flag on for a system that counts takes a slot of that flag's limit. 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 a system (a system that uses AI can also be suspended), or add more systems that use AI from your billing page.