Strategy & Metrics (SM)

Software Domain - HAIAMM v3.0

Practice Overview

Objective: Stand up an AI/HAI Software Assurance program that discovers, inventories, and strategically governs all AI/HAI software the organization builds, with shadow-AI-in-engineering prevention as the primary L1 outcome and a defensible risk-tier rubric as the primary L2 deliverable.

Description: The Software domain governs AI capabilities the organization ships, LLM-integrated applications and product features, autonomous agents, retrieval-augmented-generation (RAG) pipelines, fine-tuning and training workloads, evaluation harnesses, and the model-serving services that put models behind production traffic. SM-Software establishes the program charter, an authoritative inventory of these AI/HAI software artifacts, and the practice-maturity metrics that prove the program is working. SM L2 produces the risk-tier rubric every other Software-domain L2 practice depends on (per §9.3 of the v3.0 framing).

Context: Engineering teams adopt AI faster than security, privacy, and platform teams can review them. An LLM call gets added to a customer-facing feature in a sprint; a researcher fine-tunes a model from a Jupyter notebook in a side branch; a developer wires up an agent that touches three internal APIs and ships it behind a feature flag. None of this is malicious, it's the normal pace of AI-enabled product development. But it bypasses threat modeling (TA), requirements (SR), reference architecture (SA), design review (DR), and the deployer duties that the EU AI Act and GDPR Art. 22 place on whoever owns the production decision. The AI/HAI Software Assurance program makes this surface visible, attaches accountable ownership, and puts a light-touch intake on the path from prototype to production, so sanctioned AI features ship faster and unsanctioned ones cannot quietly accumulate.

Maturity Level 1

Objective: Stand up the AI/HAI Software Assurance program, build an inventory of AI/HAI software the organization builds, and establish baseline metrics that prove shadow AI in engineering is decreasing

At this level, the organization makes its own AI/HAI software builds visible, assigns accountability, and begins measuring the reduction of shadow AI, unsanctioned LLM integrations, ungoverned agents, and AI features shipped without security review, across the engineering population.

Dependencies

• None, entry-point practice for the Software domain. SM-Software L1 precedes all other Software-domain L1s.
• Alignment (not a hard dependency): enterprise-wide SM strategy, CISO and CTO/Head-of-Engineering governance structure, existing AppSec / SAMM program, so the AI/HAI software program plugs into existing risk committees rather than forming a parallel stack.
• Supports / unblocks: PC-Software L1 (policies need the inventory), TA-Software L1 (threat modeling needs the asset list), SR-Software L1 (requirements packs key on archetype), SA-Software L1 (reference patterns need the archetype list), IM-Software L1 (incident routing needs the owner + sponsor structure), ML-Software L1 (logging baseline needs the inventory).

Desired Outcomes

• Shadow AI in engineering is visible, attributed to a named owning team, and trending down quarter-over-quarter.
• A single AI/HAI software inventory is the authoritative source of truth across Security, Engineering, Data/ML, Product, and Privacy/Legal.
• An accountable executive owns AI/HAI software risk; decision rights for approval, block, exception, and go-live are unambiguous.
• Practice maturity is measurable from a small, automatable metric set rather than from activity counts (scans run, tickets closed).
• The program is positioned as an enabler, fast-track intake for low-risk archetypes (internal-only RAG over public docs), full review for high-risk ones (customer-facing agents acting on user accounts), so engineering teams work through it rather than around it.

Activities

A) Charter the AI/HAI Software Assurance program

Publish a short program charter that names the problem (shadow AI in engineering, ungoverned LLM integrations, agents shipped without threat modeling, fine-tunes that consume training data outside governance), defines scope, and assigns accountable ownership. The program does not need a new team, it needs a named owner and a small cross-functional working group.

Charter elements: - Problem statement, why AI/HAI software is a distinct first-party risk category (AI-specific failure modes: prompt injection, training-data leakage, tool misuse, excessive agency, agent goal hijack, rogue agents, output-integrity regression; deployer duties under EU AI Act Art. 26 fall on the org that ships the system). - In-scope AI/HAI software archetypes, LLM-integrated application or feature; autonomous AI agent (tool-using, sometimes multi-step); RAG / retrieval-augmented generation pipeline; fine-tuning or model-training workload; evaluation / red-team harness; model-serving service (own-hosted or vendor-hosted-with-our-fine-tune); classical ML model integrated into a product surface. - Executive sponsor, typically the CISO co-sponsored by the CTO / Head of Engineering / Chief AI Officer; co-signed by Privacy/Legal where applicable. - Working group, Security, Engineering (one rep per product line shipping AI), Data / ML platform, Privacy/Legal, Product, Site Reliability / Platform Engineering, one application-architect reviewer. - Decision rights, who can approve a new AI/HAI software artifact for production; who can block one; who handles exceptions; who owns the go-live gate. - Success definition for year one, a numerical target for the L1 outcome metrics below (e.g., "≥90% of AI/HAI software artifacts in production are discovered and inventoried within 12 months").

B) Build the AI/HAI software inventory and discover shadow AI

Establish a single AI/HAI software inventory as the program's source of truth. Seed it from authoritative engineering signals, then actively discover shadow AI using signals already available to platform and security teams, no new tooling required at L1.

Inventory fields (minimum): - Artifact name, owning team, archetype (LLM-integrated app, agent, RAG, fine-tune, eval harness, model-serving service, classical ML). - Production status: prototype / staged / in production / deprecated. - Customer-facing? Internal-only? Developer-only? - AI/HAI capabilities: tool use, autonomy, agent goal scope, multi-turn memory, retrieval sources, fine-tuning data sources, output-integrity-critical outputs. - Data classes processed: public, internal, confidential, regulated (PII / PHI / PCI / source code). - LLM / model provider(s) and version(s), both at inference and at fine-tuning. - Approval status: Sanctioned / Provisional / Under review / Prohibited / Awaiting Intake. - Risk tier assignment (populated at L2, see SM L2 Activity A). - Linked artifacts: TA threat snapshot, SR requirements-evidence map (REM), SA reference pattern, latest DR decision, latest IR finding, ML logging-baseline status.

Discovery sources (at L1, use what platform and security teams already have): - Source-code signals, grep the monorepo or polyrepo for LLM SDK imports (openai, anthropic, @anthropic-ai/sdk, langchain, llama_index, vertexai, google-cloud-aiplatform, transformers, vllm, bedrock), HuggingFace model downloads, vector-store clients (pinecone, weaviate, qdrant, chromadb, pgvector). - Dependency manifests, package.json, requirements.txt, pyproject.toml, go.mod, Cargo.toml, Gemfile, any AI SDK or ML library is a candidate. - CI/CD telemetry, build and deploy systems flag jobs running model training, fine-tuning, or eval harnesses; release pipelines flag deployments of services that hit AI provider endpoints. - Runtime telemetry, egress logs / service mesh / API gateway showing outbound calls to LLM provider domains from internal services. - Model and prompt registries, if you have an internal model registry (MLflow, Weights & Biases, SageMaker Model Registry, Vertex AI Model Registry), list everything in it. - Cloud spend, Bedrock / Vertex / OpenAI / Anthropic / Azure OpenAI usage on cloud bills routed by tag to owning teams. - Self-attestation, a 60-second intake form publicized to engineering through eng-all-hands and team channels; amnesty window for disclosing unsanctioned AI/HAI software already in production.

C) Establish foundational metrics that measure practice maturity and shadow AI reduction in engineering

Baseline and track a small set of outcome, process, and effectiveness metrics. Keep L1 metrics simple, automatable, and tied to the L1 outcome (shadow AI reduction in engineering and inventory coverage of what the org ships).

Shadow AI scoreboard (published quarterly to the executive sponsor): 1. AI/HAI software artifacts in inventory (total / sanctioned / provisional / prohibited / awaiting intake), broken out by archetype. 2. New AI/HAI software artifacts discovered this quarter and their intake status. 3. Shadow-AI-in-engineering ratio trend (last 4 quarters). 4. AI Acceptable Use & Engineering Standards attestation coverage across engineering headcount. 5. Top 5 unmitigated AI-specific risks (TA-flagged, ML-flagged, or external-advisory-flagged) with owners and remediation status.

Outcome Metrics (L1)

Process Metrics (leading)

• Discovery cadence, shadow-AI-in-engineering discovery sweeps (source-code + dependency-manifest + CI/CD + runtime-egress) run at least monthly.
• Intake SLA, new AI/HAI software intake triaged within 5 business days; provisional approval issued within 10 BD for low-risk archetypes.
• Inventory freshness, ≥80% of inventory records reviewed/updated in the last 90 days, tied to last-deploy timestamp.
• Working-group cadence, at least monthly; minutes published.

Effectiveness Metrics (business value)

• Engineering cycle-time impact, the time from "engineering team requests intake" to "provisional approval issued" should decrease as the program matures; the program is not a bottleneck.
• Reuse rate, % of AI/HAI software artifacts reusing a sanctioned archetype (e.g., a sanctioned RAG reference pattern) vs. inventing one from scratch; rising reuse indicates the program scales.
• Avoided-incident stories, documented cases where early discovery caught an AI-specific risk before production landing (training-data leakage in a fine-tune, prompt-injection-exposed tool call, customer-facing agent with too-broad scope).

Success Criteria

• Program charter published and sponsored by an accountable executive (CISO + CTO / Head of Engineering / Chief AI Officer).
• AI/HAI software inventory exists as a single source of truth with ≥90% coverage of discovered AI/HAI software artifacts within 12 months, broken out by archetype.
• Shadow-AI-in-engineering ratio baselined and trending down for two consecutive quarters.
• ≥95% of engineering headcount has acknowledged the AI Acceptable Use & Engineering Standards Policy.
• Quarterly shadow AI scoreboard delivered to the executive sponsor with archetype-level breakdown.

Maturity Level 2

Objective: Risk-tier the AI/HAI software inventory, calibrate the program's intensity per tier, and measure practice maturity and shadow-AI reduction per tier, establishing the tier rubric every other Software-domain L2 practice depends on

At this level, the AI/HAI Software Assurance program stops treating every artifact the same. Risk tiers drive how deep intake goes, how often reviews happen, which detections fire, and what the sponsor sees on the scoreboard. Shadow AI is measured and actively reduced against the tier-weighted profile, because one uncontrolled Critical-tier customer-facing agent is not equivalent to five Low-tier internal-only RAG prototypes. Per §9.3 of the v3.0 framing, the rubric established here is the prerequisite for L2 at TA, SR, SA, DR, IR, ST, EH, ML, and IM in the Software domain.

Dependencies

• SM-Software L1 (required): inventory, charter, working group, and baseline metrics are the substrate L2 tiers and calibrates.
• PC-Software L1 (required): the priority compliance map provides one of the tier dimensions (EU AI Act Annex III high-risk uses, GDPR Art. 22 automated decisioning, sector-specific scope).
• TA-Software L1 (required): the threat library provides another tier dimension (agentic capability, tool-misuse surface, training-data-leakage surface, output-integrity-criticality).
• Supports / unblocks: PC-Software L2 (tier-driven policy depth), TA-Software L2 (per-artifact deep threat modeling), SR-Software L2 (per-tier requirements packs), SA-Software L2 (tier-conditional reference patterns), DR-Software L2, IR-Software L2, ST-Software L2, EH-Software L2, ML-Software L2, IM-Software L2 (all per-tier calibrated).

Desired Outcomes

• Every AI/HAI software artifact in the inventory carries a risk-tier assignment tied to explicit, auditable dimensions, not reviewer vibes.
• Program intensity is visibly differentiated: Critical gets the full program (deep TA, full SR pack, full-lane DR, semi-annual IR, full ST battery, all detections, mandatory re-review on material change), Low gets the fast-track, and nobody confuses the two.
• The quarterly shadow AI scoreboard splits by tier; the sponsor can see which tiers are healthy and which are drifting.
• Tier movements (an artifact upgraded when it gains agentic capability, customer exposure, or regulated data; downgraded when scope shrinks) are a normal, tracked, sponsor-visible event, not hidden reclassifications.
• Practice maturity is now defensible per tier: "we are mature at Critical and still building at Medium" is a real, evidenced statement.

Activities

A) Define the AI/HAI software risk-tier rubric

Four tiers, Critical / High / Medium / Low, assigned from a small set of auditable dimensions specific to AI/HAI software:

• Data sensitivity processed by the artifact, regulated (PHI / PCI / regulated PII / customer source code / customer confidential) at inference or training → Critical or High.
• Decision-affecting use, AI output materially drives a decision with legal or significant effect on a person (GDPR Art. 22) or a high-risk use case under EU AI Act Annex III (hiring, credit, education, biometric, critical infrastructure, law enforcement, immigration, justice, essential services) → Critical.
• Agentic capability, the artifact is an agent with a tool surface acting on org or customer systems (executes shell commands, calls internal APIs, makes outbound HTTP, modifies records, triggers workflows) → elevate tier. Agent scope and tool count are inputs.
• User exposure, customer-facing AI feature → elevate; partner / B2B-facing → elevate; internal-employee-facing → neutral; developer-only / eval-only → lower.
• Training-data posture, fine-tuning or training on customer or regulated data → elevate; training only on public corpora → neutral.
• Production-load-bearing, artifact is on the critical path of a revenue-generating product, a customer-onboarding flow, an authentication/identity decision, or a regulated-control surface → elevate.
• Concentration / criticality, artifact is the sole AI capability behind a customer-facing product or a load-bearing internal workflow → elevate.

The rubric is documented as a short table; the tier is derived deterministically from inputs; human overrides are allowed but recorded with rationale and reviewed by the working group.

B) Calibrate program intensity per tier

Publish a tier-treatment matrix, what each tier gets from the Software-domain program. The matrix is the canonical reference every downstream practice inherits at L2.

Each downstream Software-domain L2 practice inherits this calibration and defines its own tier-specific activities, but the rubric and the matrix are authored here, in SM L2, and changes flow through the SM working group.

C) Per-tier scoreboard and governance

The L1 shadow AI scoreboard becomes tier-aware at L2: - Inventory state reported by tier and by archetype (a Critical-tier customer-facing agent is its own row; the count of Low-tier internal-only RAG prototypes is one line). - Shadow-AI-in-engineering ratio reported per tier, a Critical-tier unsanctioned AI artifact is a headline; a Low-tier one is a line item. - SLA adherence per tier (intake, DR, IR, ST, ML, IM) reported monthly. - Tier-movement log, artifacts that moved up a tier this quarter (tighter treatment now applies) and those that moved down (with rationale). - Quarterly executive review explicitly discusses tier-balance, is the program's effort matching the program's risk profile?

Outcome Metrics (L2)

Process Metrics (leading)

• Tier-rubric review cadence, reviewed every 2 quarters; changes change-logged.
• Tier calibration exercise, at least quarterly, a sample of 20 artifacts re-tiered by a second reviewer; drift tracked.
• Per-tier queue depth monitored; no tier's backlog exceeds a published threshold.
• Working-group sprint to onboard the next downstream practice's L2 calibration.

Effectiveness Metrics (business value)

• Effort allocation match, % of reviewer hours spent on Critical+High tiers vs. Medium+Low; should rise relative to L1.
• Engineering throughput at Low/Medium tiers, sanctioned-archetype reuse accelerates ship time vs. greenfield design.
• Avoided-incident stories where tier-differentiation caught risk earlier (Critical-tier agent caught at DR vs. shipped and discovered in incident).
• Scoreboard drives budget, tier-level dashboards referenced in quarterly engineering planning.

Success Criteria

• Risk-tier rubric published and applied; tier assigned to 100% of inventory.
• Tier-treatment matrix published; downstream practices (PC, TA, SR, SA, DR, IR, ST, EH, ML, IM) calibrated to it.
• Per-tier shadow AI ratio reported quarterly; Critical-tier unsanctioned AI in production = 0.
• Per-tier SLA adherence ≥90% across practices.
• Tier-movement governance active, changes logged with rationale and reviewed by the sponsor.

Maturity Level 3

Objective: Automate inventory and tier maintenance from live build/deploy/runtime signals, benchmark the program against external peers, and contribute anonymized AI/HAI software ecosystem intelligence back to the industry

At this level, the program is predominantly signal-driven rather than ticket-driven. Inventory and tiering update from authoritative engineering feeds (CI/CD, model registries, dependency manifests, runtime telemetry); human review is exception-based. The program can state where it stands against peers on specific metrics, and gives back to the AI/HAI software assurance ecosystem through standards bodies, ISACs, MITRE ATLAS submissions, OWASP LLM / Agentic Top 10 contributions, AI Vulnerability Database submissions, and open-source security reference patterns.

Dependencies

• SM-Software L2 (required): tiering and calibration must be settled before automation is trustworthy.
• ML-Software L2+ (required): signals (CI/CD events, model-registry events, runtime egress, prompt/completion logs, tool-call telemetry) need the monitoring pipeline behind them.
• EG-Software L2+ (required): the engineering literacy that lets teams self-attest inventory accurately at the artifact level.
• Supports / unblocks: the other 11 Software-domain practices can move to L3 automation patterns because SM now supplies automated inventory and tier data.

Desired Outcomes

• Inventory accuracy is measured in hours-of-latency, not months.
• Tier assignments adjust automatically when dimensional inputs change (new tool added to an agent, new data class flows into a fine-tune, customer-exposure switched on for a previously internal feature); humans intervene only on exceptions.
• External benchmarking is routine, the program sponsor can answer "how do we compare?" with specific deltas, not hand-waving.
• The organization is a net contributor to the AI/HAI software assurance ecosystem, industry references point back to us, not only outward from us.
• The program's strategic ROI is demonstrable: dollars of program investment mapped to dollars of avoided loss (incidents prevented, regulatory exposure mitigated, faster sanctioned ship time), with external benchmarks reinforcing the narrative.

Activities

A) Continuous inventory and tier automation from build/deploy/runtime signals

• Inventory auto-updates from: CI/CD events (job-type tags for training, fine-tuning, eval, deploy), model-registry events (new model registered, version promoted, deprecated), dependency-manifest scanning on commit (new LLM SDK or vector-store client imported), runtime egress (new outbound flow to AI provider domain), prompt/completion log volumes (sudden new artifact emitting prompts is a discovery signal), self-attestation, intake.
• Tier assignments are rule-based on the L2 rubric inputs; rule changes are versioned and replayable; tier changes auto-trigger downstream practice obligations (e.g., a Medium→Critical upgrade triggers DR, ST, ML reconfiguration).
• Human curation handles: new archetypes (e.g., a new multi-agent-platform pattern that doesn't fit prior archetypes), ambiguous discoveries (a shared library that may or may not be in production), dimensional-input conflicts.
• A data-quality SLO is published: ≥99% of active AI/HAI artifacts correctly tiered within 48 hours of a material change; ≥95% inventory completeness against discovery-source reconciliation.

B) External benchmarking

• Program metrics compared against peer benchmarks via:
• OWASP SAMM AI extensions / OpenSSF AI / CSA AI Safety Initiative working groups.
• BSIMM-style observational data on what comparable orgs ship in AI/HAI software.
• MITRE ATLAS practitioner data exchanges.
• Sector ISACs with AI working groups (FS-ISAC, H-ISAC, IT-ISAC, sector ones).
• Formal peer roundtables (CISO communities, AI safety practitioner circles).
• A published "how we compare" brief refreshed semi-annually covers: inventory coverage, shadow-AI ratio, per-tier SLA adherence, automation level, IR drift detection rate, ST coverage rate, time-from-intake-to-provisional-approval.
• Benchmark deltas inform program investment, board-level narrative, and the next year's L2 / L3 work priorities.

C) Contribute anonymized AI/HAI software ecosystem intelligence

• Contribute to:
• MITRE ATLAS (new TTPs observed in own-built AI/HAI software).
• OWASP LLM Top 10 / Agentic Top 10 (review, comment, real-world telemetry from prompt/completion + tool-call corpora).
• NIST AI RMF Playbook and successor editions.
• AI Vulnerability Database (AVID) submissions for own-discovered software-side issues (responsibly disclosed where they touch upstream models / libraries).
• OpenSSF AI working groups (reference patterns, dependency-manifest signatures, supply-chain advisories for AI tooling).
• ISO/IEC 42001 AIMS community where applicable.
• Target: minimum 4 substantive contributions per year; quality over volume; every contribution anonymized and legally vetted.

Outcome Metrics (L3)

Process Metrics (leading)

• Automation health, signal-feed freshness and error rate monitored; on-call paged when a feed staleness threshold exceeded.
• Benchmarking cadence honored (semi-annual brief published on schedule).
• Contribution pipeline always has ≥2 items in-flight (draft, in-review, or being prepared).
• Tier-rule change-log healthy, rule changes versioned, replayable, reviewed quarterly by the working group.

Effectiveness Metrics (business value)

• Sponsor decisions (budget, headcount, scope) citing benchmark data and tier-level metrics.
• Industry recognition, invitations to working groups, citations of the program's contributions, peer adoption of published reference patterns.
• Talent, the program attracts experienced AppSec / AI-safety reviewers because of its external profile.
• Faster sanctioned ship time, the time from "engineering team proposes a new AI feature" to "provisional approval issued" is industry-leading.

Success Criteria

• Inventory auto-update SLO published and met.
• Tier-assignment automation operational with published rules, replayable change-log, and exception-based human review.
• Semi-annual external-benchmarking brief published to the sponsor with ≥5 peer-comparable metrics.
• ≥4 substantive industry contributions per year, anonymized and cited.
• ROI narrative including external benchmarks delivered to exec/board at least annually.

Key Success Indicators

Level 1: - AI/HAI Software Assurance program charter published and sponsored by an accountable executive (CISO + CTO / Head of Engineering / Chief AI Officer), with a cross-functional working group (Security, Engineering, Data/ML, Privacy/Legal, Product, Platform/SRE, application-architect reviewer). - AI/HAI software inventory exists as a single source of truth, covering all in-scope archetypes (LLM-integrated app, agent, RAG, fine-tune/training, eval harness, model-serving service, classical ML). - Shadow AI in engineering actively discovered each month from source-code, dependency-manifest, CI/CD, runtime-egress, model-registry, and cloud-spend signals, reconciled against the inventory. - AI Acceptable Use & Engineering Standards Policy acknowledged by ≥95% of engineering headcount. - Foundational metrics baselined: inventory coverage, shadow-AI-in-engineering ratio, AUP attestation, intake SLA; quarterly shadow AI scoreboard delivered to the exec sponsor with archetype-level breakdown.

Level 2: - Risk-tier rubric published and applied, 100% of inventory carries a current tier from auditable dimensions (data sensitivity, decision-affecting use, agentic capability, user exposure, training-data posture, production-load-bearing, concentration). - Tier-treatment matrix published; downstream practices (PC, TA, SR, SA, DR, IR, ST, EH, ML, IM) calibrated to it. - Quarterly shadow AI scoreboard reports per tier and per archetype; Critical-tier unsanctioned AI in production = 0. - Per-tier SLA adherence ≥90% across program activities. - Tier-movement governance operating with logged rationale and sponsor review.

Level 3: - Inventory auto-update latency ≤48 hours for material changes; ≥80% of curation is automated; ≥99% inventory completeness against discovery-source reconciliation. - Tier-assignment automation operates on a published, versioned rule set with exception-based human review; tier changes auto-trigger downstream practice obligations within 24 hours. - Semi-annual external-benchmarking brief published to the sponsor, citing at least five peer-comparable metrics from OWASP SAMM AI / OpenSSF / MITRE ATLAS / sector ISACs. - ≥4 substantive anonymized industry contributions per year (MITRE ATLAS / OWASP LLM / Agentic Top 10 / NIST AI RMF / AVID / OpenSSF AI / sector ISACs). - Executive / board ROI narrative refreshed at least annually with external benchmarks and documented avoided-loss examples.

Common Pitfalls

Level 1: - ❌ Inventory is seeded only from "AI features the product team announced", misses unannounced LLM calls embedded in pre-existing features, internal-tool LLM integrations, eval-harness data flows, and fine-tunes run from researcher notebooks. - ❌ Treating "AI features inside our own apps that call vendor APIs" as a Vendors-domain concern, they are first-party Software (we ship the feature; we own deployer duties); the vendor question is a sub-concern. - ❌ Program positioned as a blocker, intake SLA unpublished, engineering cycle time balloons, product teams route around the program by shipping behind feature flags. - ❌ Executive sponsor is security-only; CTO / Head of Engineering / Chief AI Officer are not co-owners, so the program lacks engineering authority. - ❌ Metrics count activity (scans run, tickets closed, reviews completed) instead of outcomes (shadow-AI-in-engineering ratio down, AUP coverage up, AI-specific incidents trending down). - ❌ No amnesty window for self-disclosure, engineers hide unsanctioned AI features rather than surface them. - ❌ Inventory archetypes too coarse ("AI feature"), Critical agents and Low eval-only RAGs get conflated; the program cannot tier later without re-inventorying.

Level 2: - ❌ Tier-rubric inputs are subjective ("important," "sensitive"), reviewers tier differently; auditors don't trust it; tier movements feel political. - ❌ Tier-treatment matrix published but not enforced, Critical artifacts routed to the same queue as Low; calibration exists on paper only. - ❌ Scoreboard still reported in aggregate, hiding that Critical-tier shadow AI is present because overall averages look fine. - ❌ Tier upgrades get resistance from engineering teams because they trigger more work, no governance on tier-movement leaves the program stuck at initial assignments. - ❌ Downstream practices treat tier as advisory, not operational, DR/IR/ST/ML don't differentiate their scope by tier, defeating the purpose of L2. - ❌ Rubric over-engineered, too many dimensions, too many edge cases, tier-derivation becomes an oracle ritual rather than a deterministic computation.

Level 3: - ❌ Automation runs without a data-quality SLO, signal-driven inventory silently drifts and humans stop trusting it. - ❌ Benchmarking chooses peers that flatter the program instead of stretching it (chose Series-A startups when you ship to enterprise; chose internal-tool builders when you ship customer-facing AI). - ❌ Industry "contributions" are press releases and conference talks, not technical artifacts that actually land in MITRE / OWASP / NIST / AVID / OpenSSF. - ❌ Automated tiering rules encode historical bias (weighted against archetypes the program under-reviewed, under-weighted for ones the program prefers), audit of rule inputs never happens. - ❌ ROI narrative decouples from reality, external benchmarks cited but the program's own metrics are stale; sponsor stops trusting the deck. - ❌ Tier-change downstream-trigger automation fires too noisily, every prompt-template tweak triggers a re-review; engineering teams disable the signal-source rather than fix the rule sensitivity.

Practice Maturity Questions

Level 1: 1. Is there a published AI/HAI Software Assurance program charter with a named executive sponsor (CISO + CTO / Head of Engineering / Chief AI Officer), a cross-functional working group, and clear decision rights for approval, block, exception, and go-live? 2. Does a single AI/HAI software inventory exist, seeded from source-code, dependency-manifest, CI/CD, runtime-egress, model-registry, and cloud-spend signals, covering all in-scope archetypes (LLM-integrated app, agent, RAG, fine-tune/training, eval harness, model-serving service, classical ML), with ≥90% coverage of discovered artifacts within 12 months? 3. Are the L1 outcome metrics baselined and reported quarterly to the sponsor, inventory coverage, shadow-AI-in-engineering ratio (≤15% and trending down), AUP attestation (≥95% of engineering), AI/HAI artifacts with named owning team (100%), and known data-exposure events from AI/HAI software?

Level 2: 1. Is every AI/HAI software artifact in the inventory assigned a risk tier based on an auditable rubric covering data sensitivity, decision-affecting use (EU AI Act Annex III / GDPR Art. 22), agentic capability, user exposure, training-data posture, production-load-bearing, and concentration? 2. Is there a published tier-treatment matrix driving differential intensity across PC, TA, SR, SA, DR, IR, ST, EH, ML, IM, with ≥95% of Critical-tier artifacts receiving full-scope treatment in the last 12 months? 3. Does the quarterly shadow AI scoreboard report per tier and per archetype (with Critical-tier unsanctioned AI in production explicitly tracked at zero), and does tier-movement get logged and reviewed by the program sponsor?

Level 3: 1. Does inventory and tier assignment auto-update from live build/deploy/runtime signals (CI/CD, model registries, dependency manifests, runtime egress, prompt/completion telemetry, intake, self-attestation) with a published data-quality SLO, and is ≥80% of curation handled automatically with exception-based human review? 2. Do you publish a semi-annual external-benchmarking brief comparing the program against at least five peer-comparable metrics via OWASP SAMM AI / OpenSSF / MITRE ATLAS / sector ISACs, and does it drive program investment decisions? 3. Does the program contribute at least four substantive, anonymized artifacts per year to the AI/HAI software ecosystem (MITRE ATLAS, OWASP LLM/Agentic Top 10, NIST AI RMF, AVID, OpenSSF AI, sector ISACs), and does the exec/board ROI narrative cite external benchmarks?

Document Version: HAIAMM v3.0 Practice: Strategy & Metrics (SM) Domain: Software Last Updated: 2026-05-12 Author: Verifhai