Skip to main content

7. Onboarding: Register New AI System

Functional Documentation​

1) Step-Based Onboarding Flow​

Purpose: Guided 5-step wizard in Register New AI System.

Steps:

  1. System Basics
  2. Model & Lifecycle
  3. Business Context
  4. Compliance Controls
  5. Review & Launch

Main actions:

  • Entry trigger: + Register New AI System
  • Footer navigation: Cancel, Back, Continue, Review & Create, Create System
  • Top-right close (X)

Behavior:

  • Progress bar and step indicator (Step X of 5)
  • Step validation before navigation:
    • System name is required
    • At least one model is required

2) System Basics: Name + Business Description​

Fields:

  • System Name
  • Description / Intended Purpose

Main action:

  • Continue

Notes:

  • Description is used downstream for automation, risk suggestions, and documentation generation.

3) Model & Lifecycle​

Fields:

  • LLM Models (multi-select tags; one or more required)
  • Lifecycle Status: draft / in_review / live

Main action:

  • Continue

Notes:

  • Runtime telemetry is based on the model actually sent by SDK traffic, not only the default catalog selection.

4) Business Context (ROI Inputs)​

Fields:

  • Toggle: Not applicable / does not replace human labor
  • If toggle is OFF:
    • Human Role Replaced
    • Avg. Human Hourly Cost
    • Time per Task

Main action:

  • Continue

Behavior:

  • If Not applicable is ON, ROI fields are cleared and stored as null (N/A).

5) Risk Classing​

Fields:

  • Toggle: Is High Risk System? (Annex III)

Behavior:

  • Sets regulatory posture expectations and stricter governance obligations.

Declared risk signals:

  • Payload includes declaredRisks:
    • db_access
    • pii_handling
    • public_facing
    • custom
  • In current onboarding UI, these are initialized with defaults and not edited explicitly in the wizard.

6) Control Mode: Active Guard vs Shadow Mode​

Field:

  • Toggle: Shadow Mode (Observability Only)

Behavior:

  • Active Guard: enforcement can block/mask based on policy.
  • Shadow Mode: monitor-only, no active blocking/masking, fail-open by design.

7) Strict Security: Fail-Open vs Fail-Closed​

Field:

  • Toggle: Strict Security (Fail-Closed)

Behavior:

  • In active mode:
    • ON -> fail-closed on technical failures.
  • In shadow mode:
    • forced OFF (disabled), because shadow mode is fail-open by design.

8) AI Analysis Toggle​

Field:

  • Toggle: Enable AI Security Analysis

Behavior:

  • ON -> AI-assisted checks + deterministic checks.
  • OFF -> deterministic checks only.
  • In shadow mode -> forced ON (locked) to preserve monitoring completeness.

9) Operational Restrictions Toggles​

Fields:

  • Block Prompt Injection
  • Block Database Access (SQL/NoSQL)
  • Block Code Execution (RCE)
  • Block Toxicity & Profanity
  • Block PII / Sensitive Data (Strict Mode)

Behavior:

  • In active mode: each toggle is enforceable.
  • In shadow mode: restriction toggles are disabled and non-enforcing.

PII strict mode note:

  • Enabling strict PII mode warns that streaming is disabled in affected SDK flows.

10) Final Review Summary Before Creation​

Summary includes:

  • Name, models, lifecycle
  • Guarding mode
  • Risk class
  • AI analysis status
  • Blocking toggle states
  • Strict security state
  • ROI context values

Main action:

  • Create System

Post-create note:

  • Telemetry capture and compliance evidence collection start immediately after creation.