Skip to main content

AIPS Guidance: HDIP Decision Framework for AI Products

1. Preamble​

1.1 Background​

Large enterprises have historically governed software systems through structured control mechanisms such as:

  • ITSM (IT Service Management)
  • CMDB (Configuration Management Database)
  • Change Management Processes (CR, CAB, Releases)
  • Application Identity (APP_ID)

These mechanisms evolved to ensure:

  • Traceability
  • Accountability
  • Risk control
  • Auditability

Every application deployed into production is expected to:

  • Have a unique APP_ID
  • Be registered as a Configuration Item (CI)
  • Have clearly assigned ownership roles (e.g., ITAO, BIRO, TISO)
  • Follow formal change management workflows

1.2 The Risk of “Shadow IT” in the Age of AI​

With the rise of AI and agentic systems, organizations are experiencing:

  • Rapid experimentation
  • Decentralized development
  • API-based model access
  • Prompt-driven behavioral changes

Without proper integration into enterprise control systems, this leads to:

⚠️ Shadow AI / Shadow IT in the name of innovation

Risks include:

  • Untracked AI deployments
  • Lack of ownership and accountability
  • Regulatory non-compliance
  • Undocumented behavioral changes
  • Inability to audit decisions made by AI systems

1.3 The HDIP Shift​

Under HDIP:

  • Development shifts from project-based engineering → product-based creation
  • Ownership shifts from engineering roles → AIPRO (AI Product Owner)
  • Execution shifts from manual SDLC → Product Factory Intelligence (PFI)

However:

❗ HDIP does NOT eliminate enterprise control systems like ITSM or CMDB

Instead:

✅ HDIP re-orchestrates them through PFI using product artifacts

2. Context​

AI Products differ fundamentally from traditional applications and data products:

DimensionData ProductAI Product
NatureDeterministicBehavioral / Probabilistic
OutputDataDecisions / Actions
AutonomyNonePossible
Risk ProfilePassiveActive
GovernanceData policiesRisk + Behavior + Policy

AI Products can:

  • Make decisions
  • Trigger actions
  • Impact customers or external systems
  • Operate with varying levels of autonomy

This creates new operational risk boundaries that must be governed.

3. Problem Statement​

Traditional ITSM assumes:

“One application = one control boundary = one APP_ID”

However, AI systems are:

  • Composed of multiple components (models, APIs, pipelines)
  • Often embedded within platforms like HDIP aligned platform
  • Behavior-driven rather than system-bound

This creates ambiguity:

  • Should every AI Product have an APP_ID?
  • Should all AI Products be governed under a platform APP_ID (e.g., HDIP aligned platform )?
  • How do we avoid overloading ITSM while preventing Shadow AI?

4. Guidance for AIPRO and HDIP Platform Providers (PFI)​

4.1 Core Principle​

APP_ID is not assigned based on product type, but based on operational risk boundary.

4.2 Responsibility Model​

  • AIPRO:

    • Owns product intent
    • Owns risk acceptance
    • Owns decisions

  • PFI:

    • Orchestrates SDLC workflows
    • Integrates with ITSM, CMDB, CI/CD
    • Generates audit and governance artifacts

❗ PFI is an execution agent NOT the product owner

4.3 Decision Framework for APP_ID Assignment​

PFI MUST evaluate the following axes for every AI Product:

  1. Autonomy Level (AL) – Degree of independent decision-making
  2. Action Scope (AS) – Ability to trigger actions
  3. Exposure Boundary (EB) – Scope of impact
  4. Risk Tier (RT) – EffectiveRiskTier (R0–R4)

4.4 Decision Flow​

4.5 Interpretation​

Case 1 — No APP_ID​

  • Low autonomy
  • No direct action
  • Internal scope
  • Low–moderate risk

→ Governed within HDIP aligned platform's APP_ID

Case 2 — Conditional APP_ID​

  • Moderate autonomy or action
  • Enterprise-level impact
  • High (R3) risk

→ Use Logical APP_ID or Enhanced Governance

Case 3 — Mandatory APP_ID​

  • Autonomous decision-making
  • Direct action execution
  • External/customer impact
  • Critical risk (R4)

→ Requires independent APP_ID and full ITSM integration

4.6 PFI Implementation Expectations​

PFI MUST:

  1. Automatically evaluate AI Product characteristics

    • Infer AL, AS, EB, RT

  2. Determine APP_ID strategy

    • None / Logical / Full

  3. Integrate with ITSM

    • Auto-create Change Requests (CR)
    • Route approvals based on risk

  4. Synchronize with CMDB

    • Register AI Products as CIs (logical or physical)

  5. Enforce governance checkpoints

    • Require explicit AIPRO approval where needed

  6. Generate audit artifacts

    • Link AIPROD, AIPDS, Risk Tier, and approvals

5. Key Principles​

  • Ownership cannot be delegated to the platform
  • Automation must not bypass accountability
  • Control must be deterministic and computable
  • PFI must be invisible to AIPRO but fully compliant with enterprise governance

6. Final Statement​

AI Products that behave like systems must be governed like systems.

APP_ID is a control identity, not a product identity.

PFI is the compiler of enterprise control systems in an HDIP world.