Skip to main content

7. Onboarding: Register New AI System

Functional Documentation​

1) Step-Based Create Flow​

Purpose: Guided, short setup flow in Register New AI System.

Steps:

  1. Setup
  2. Controls
  3. Business Context (SDK and hybrid deployments only)
  4. Review & Launch

Browser-only systems skip Business Context during create, so the create flow is 3 steps.

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 N)
  • Step validation before navigation:
    • System name is required
    • At least one SDK model is required for SDK or hybrid deployments
    • At least one browser provider is required for browser or hybrid deployments
    • Business Context values are required unless marked not applicable

2) Setup: Name, Deployment Mode, and Runtime Coverage​

Fields:

  • System Name
  • Description / Intended Purpose
  • Deployment Mode: Browser Rollout, SDK / API, or Hybrid
  • Browser providers: ChatGPT, Gemini, Copilot
  • LLM Models for SDK and hybrid systems

Main action:

  • Continue

Notes:

  • Description is used downstream for automation, risk suggestions, and documentation generation.
  • Browser provider selection determines browser-extension runtime coverage.
  • SDK model selection defines the initial model catalog for API/SDK traffic.

3) Controls​

Purpose: Define the initial enforcement posture without forcing a full compliance setup during create.

Fields:

  • Shadow Mode (Observability Only)
  • Enable AI Security Analysis
  • Block Prompt Injection
  • Block Database Access (SQL/NoSQL) for SDK and hybrid systems
  • Block Code Execution (RCE) for SDK and hybrid systems
  • Block Toxicity & Profanity
  • Block Personal Information
  • Masking Personal Information
  • Strict Security (Fail-Closed) for SDK and hybrid systems

Main action:

  • Continue

Behavior:

  • New systems start live by default.
  • Active Guard: enforcement can block or mask based on policy.
  • Shadow Mode: monitor-only, no active blocking or masking, fail-open by design.
  • In shadow mode:
    • Strict Security is forced OFF
    • active blocking and masking toggles are disabled
  • In active mode:
    • Strict Security enables fail-closed behavior on technical failures
    • AI Analysis toggles AI-assisted checks
    • blocking toggles are individually enforceable
  • Enabling strict personal-information blocking can disable streaming in affected SDK paths to guarantee full redaction.

4) Business Context (ROI Inputs)​

Shown for: SDK and hybrid deployments.

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) Final Review Summary Before Creation​

Summary includes:

  • Name and deployment mode
  • Browser provider coverage when applicable
  • SDK model catalog when applicable
  • Guarding mode
  • AI analysis status
  • Blocking and masking toggle states
  • Strict security state where applicable
  • ROI context values where applicable

Main action:

  • Create System

Post-create note:

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

Edit Existing Systems​

Purpose: Editing an existing system keeps the already-filled system view as the starting point.

Dashboard card behavior:

  • The pencil icon and Edit menu action switch the system card into inline edit mode.
  • Inline edit supports quick changes to:
    • System name
    • Lifecycle status
    • Description / intended purpose
  • Save persists the quick edits immediately.
  • Reset restores the current saved values.

Full configuration edits:

  • Advanced configuration remains available in the system detail areas such as Guardrails, Integration, Data, Compliance, and Settings.
  • Existing systems are not sent back through the create onboarding flow just to edit basic fields.

Advanced Governance Controls​

Purpose: Capture domain intent, governance tier, and regulatory scope after the system exists.

Fields:

  • Purpose Category
    • Finance & Insurance
    • Customer Support
    • Software & Engineering
    • Creative & Marketing
    • Healthcare
    • Legal & Compliance
    • Education & Training
    • Family & Youth
    • Other
  • Custom Category
    • required only when Other is selected
  • Governance Tier
    • Tier 1 (Full Governance / Enterprise)
    • Tier 2 (Standard Governance)
    • Tier 3 (Basic Monitoring)
  • Compliance multi-select:
    • AI Act
    • ISO 42001
    • Colorado AI Act
    • Custom
    • Not relevant
  • Conditional inputs:
    • AI Act Risk Class when AI Act is selected
    • Custom compliance label when Custom is selected

Behavior:

  • Purpose category is converted into domain-context defaults in the security configuration.
  • The onboarding form no longer asks users to manually write sensitivity, normal topics, or blocked topics.
  • Governance Tier sets the initial operating posture and maps into downstream risk/governance expectations.
  • If AI Act is selected in compliance frameworks, the onboarding flow also requires an AI Act class:
    • High Risk
    • Limited Risk
    • Minimal Risk
  • Not relevant clears the compliance multi-select and stores the onboarding governance section as intentionally not applicable.