Education & Guidance (EG)

Software Domain - HAIAMM v3.0

Practice Overview

Objective: Build the AI-assurance literacy every engineer touching AI/HAI software needs and the practitioner skills the smaller population performing threat modeling, secure code review, security testing, architecture review, and red-teaming of AI systems must have, with shadow AI in engineering awareness as the primary L1 cultural outcome.

Description: EG-Software covers two audiences. The first is the entire engineering population building or shipping in-scope AI/HAI software archetypes (LLM-integrated applications, agents, RAG pipelines, fine-tune/training workloads, eval harnesses, model-serving services, classical ML models), they need AI-assurance literacy: what the archetypes are, what the seven HAI TTPs mean for the code they write, what the AI Acceptable Use & Engineering Standards policy requires, how the go-live gate works, and what a sound requirement-evidence map looks like. The second is the practitioner population, AppSec reviewers, AI/ML platform engineers, application architects doing AI-feature reviews, and red-teamers, who need deep, hands-on skills covering ATLAS tactics, OWASP LLM / Agentic Top 10, prompt-injection patterns, agent goal-hijack recognition, tool-misuse detection, training-data poisoning indicators, output-integrity testing, and kill-switch design. EG-Software defines the outcomes the program must produce and how the organization measures whether those outcomes are actually reached.

Context: AI-specific vulnerabilities, prompt injection (AGH), excessive agency (EA), tool misuse (TM), rogue agent drift (RA), training-data leakage, output-integrity regression, are not covered by classic AppSec curricula. Engineers adopting LLM features, RAG pipelines, and agent platforms learn the API surface but rarely the adversarial model. A developer who has only taken the org's OWASP Top 10 course will build an agent without thinking about goal-hijack scenarios, and an AppSec reviewer trained only on SAST and DAST findings will not recognize a prompt-injection vector in a tool-call argument. Without a deliberate EG practice targeted at these gaps, AI security surfaces late, at incident time, in external audits, or in customer questionnaires. L1 EG-Software ships the minimum viable literacy for everyone building AI/HAI software and the minimum viable practitioner track for those who review it. L2 extends into scenario-based reviewer training, product-line-specific tracks, and seasonal shadow-AI campaigns. L3 externalizes the curriculum and contributes to emerging AI-engineering certification pathways.

Maturity Level 1

Objective: Deliver foundational AI-assurance literacy to ≥95% of the engineering workforce building AI/HAI software and role-based practitioner training to 100% of the reviewer population, with an active shadow-AI-in-engineering awareness campaign

At this level, the organization ensures that every engineer who touches AI/HAI software can identify AI-specific risks and navigate the program's policies and gate, and that the reviewer population can perform consistent threat modeling, code review, and security testing against AI/HAI archetypes.

Dependencies

• PC-Software L1 (required): the three priority policies (AI Engineering Standards, AI AUP, Intake / Go-Live Gate) and the priority compliance map are the primary teaching object, training without published policies is hollow. EG-Software L1 cannot precede PC-Software L1.
• SM-Software L1 (required): the AI/HAI software inventory and archetype taxonomy define what the training is about and which archetypes engineers will encounter.
• Alignment (not a hard dependency): enterprise LMS and existing security-awareness program, extend rather than duplicate; engineering all-hands cadence for shadow-AI-in-engineering campaign launch.
• Supports / unblocks: every downstream practice, reviewers who cannot distinguish an agent from a RAG pipeline will not produce useful threat models (TA), requirements (SR), design reviews (DR), implementation reviews (IR), or security tests (ST).

Desired Outcomes

• Any engineer building AI/HAI software can name the archetypes the org sanctions, cite the two or three AUP rules most relevant to their work, describe one HAI TTP relevant to their archetype, and submit an intake ticket or disclose prior unsanctioned use in under 5 minutes.
• The reviewer population (AppSec reviewers, AI/ML platform engineers, AI-feature architects, red-teamers) produces consistent, evidence-backed reviews, two practitioners independently reviewing the same agent intake arrive at the same threat snapshot and the same SR gap list.
• Shadow AI disclosures increase in the first two quarters after the campaign launches (awareness working), then decrease as the sanctioned-archetype program grows (adoption working).
• Deployer-duty obligations under EU AI Act Art. 26 are not abstract, every reviewer can map a customer-facing agent to the human-oversight assignment, logging requirement, and disclosure obligation it triggers.
• Training content is owned, dated, and updated within 30 days of any change to the AUP, intake policy, archetype list, or priority compliance map.

Activities

A) Ship engineering workforce AI-assurance literacy training

A single short course (≤20 minutes) every engineer takes on hire and refreshes annually, tied to the AI AUP attestation from PC-Software L1. This is not a comprehensive secure coding course, it is the minimum AI-assurance literacy needed to participate in the AI/HAI software program without creating compliance exposure.

Content (minimum): - What the AI/HAI software archetypes are, the seven archetypes sanctioned by the org (LLM-integrated app or feature, autonomous AI agent, RAG / retrieval-augmented-generation pipeline, fine-tuning or model-training workload, evaluation / red-team harness, model-serving service, classical ML model integrated into a product surface). Concrete examples from the org's own inventory. - The AI AUP in five rules, sanctioned archetypes and SDKs, prohibited data-class flows, approval required before fine-tuning on regulated data or wiring up an agent, disclosure obligation to the inventory, attestation requirement. - The HAI TTPs in plain language, Excessive Agency (EA): the agent can do more than it should; Agent Goal Hijack (AGH): injected content redirects the agent's goal; Tool Misuse (TM): the agent's tools are invoked for attacker purposes; Rogue Agent (RA): autonomous drift from intended behavior. Plus: prompt injection, training-data leakage, output-integrity regression. One concrete engineering example per TTP matched to a relevant archetype. - The go-live gate, how to submit intake, what the per-archetype artifacts checklist requires, what "provisional approval" means, and how the amnesty path works. - What a good requirement-evidence map (REM) looks like, a one-screen example showing a base requirement linked to its evidence artifact, an accepted gap with owner and expiry, and a compensating control. - Before-you-connect decision aid, a 10-second check: is this archetype in the inventory? Is the data class permitted? Does this scope require intake approval before I connect or ship?

Delivery: LMS module + 1-page reference card pinned in engineering Slack/Teams + brief at engineering all-hands when the program launches. No role gating, every engineer building or operating AI/HAI software takes the same workforce-level module.

B) Deliver role-based practitioner training for the reviewer population

A deeper module (~2 hours) for the practitioner population only: AppSec reviewers performing TA and SR intake reviews, AI/ML platform engineers running model-serving and fine-tuning infrastructure, application architects reviewing AI-feature designs in DR, and red-teamers running ST exercises. This is where the specific AI/HAI security review skill gets built. Completion is a prerequisite to approving intakes, not optional.

Content (minimum): - MITRE ATLAS tactics walkthrough, all 14 ATLAS tactics applied to the org's archetypes: Reconnaissance → ML Model Access → ML Attack Staging → Exfiltration → Impact, with Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Collection sub-tactics. One example per tactic anchored to an org archetype. - OWASP LLM Top 10 and OWASP Agentic Top 10, mapping each entry to the archetype(s) where it is most relevant; practitioner judgment on severity. - Prompt injection in depth, direct and indirect injection patterns; how retrieved content, tool responses, and multi-turn history become injection vectors (AGH TTP); detection and mitigation at architecture and code level. - Agent goal-hijack scenarios, multi-step agent goal drift; how a benign agent goal is redirected via a crafted document, API response, or multi-agent coordination channel (AGH + RA TTPs combined); recognition patterns in code review and SA review. - Tool-misuse pattern recognition, argument smuggling into tool calls; unexpected tool-call combinations; recursive invocation; crafted parameters that exceed the tool's intended scope (TM TTP); how to assess tool-scope boundary in an SR REM. - Training-data poisoning indicators, how poisoned fine-tuning data manifests in model behavior; what to look for in a training-data provenance record; no-train and retention verification in a DPA vs. in runtime logs. - Output-integrity testing, regression corpora for jailbreaks and prompt injections; data-egress canary design; kill-switch and human-override path testing; logging-completeness verification. - Kill-switch and human-override design, what a tested kill-switch looks like in an agent deployment; how to confirm it in DR and IR; what "human oversight" under EU AI Act Art. 26 actually requires at the engineering level. - Priority compliance map in practice, given an archetype, which requirements from PC's map apply, where the evidence lives in the go-live gate record, and what an auditor will ask. - Calibration exercise, three sample archetype intakes (e.g., a customer-facing agent, a fine-tune on internal data, a RAG pipeline over public docs) scored independently; facilitated debrief on tier assignment, TTP identification, and SR gap list.

Delivery: instructor-led or recorded workshop + role-specific reference job aids (one per archetype: "what to look for in a [agent / RAG / fine-tune] intake") + quarterly calibration session. Completion gated on intake-approval permissions.

C) Run the shadow-AI-in-engineering awareness campaign

An always-on communications program making it uncomfortable to ship AI/HAI features outside the program and easy to surface them. L1 target is a sustainable, lightweight cadence.

Campaign elements: - Launch moment, executive sponsor message naming shadow AI in engineering, announcing the amnesty window, and publishing the sanctioned-archetype catalog. Explicit framing: the program is an enabler (fast-track for Low-tier) not a blocker. - Recurring short content, monthly one-paragraph pieces: new archetype approved and available, a fast-track win (intake to provisional approval in 3 BD), an anonymized example of a TTP caught during intake review (with team permission), an external incident reframed as "what would we find if we checked our own inventory?". - "Is this AI?" series, periodic call-outs of AI features silently shipping in internal tooling or added behind feature flags, with clear instruction on whether existing gate coverage applies. - Amnesty visibility, the path to disclose prior unsanctioned AI/HAI software is linked from the AUP, the intake form, and the engineering Slack/Teams channel pins. Amnesty is prominent, not buried. - Feedback channel, a visible channel for engineers to nominate archetypes or SDK patterns for the sanctioned catalog; nomination is triaged and acknowledged within 5 BD. - Deployer-duty micro-content, short explainers for teams shipping customer-facing or decision-affecting AI features: what human oversight means at the code level, what the logging baseline is, what the disclosure obligation looks like in a product UI.

Measurement: campaign channel links are tagged so attribution of intake submissions and amnesty disclosures to campaign touchpoints is tracked.

Outcome Metrics (L1)

Process Metrics (leading)

• Workforce training content reviewed quarterly; updated within 30 days of any change to the AUP, archetype list, or priority compliance map.
• New-hire coverage SLA, AI-assurance literacy completed within 30 days of start.
• Reviewer calibration cadence, at least once per quarter; drift trends reported to the program sponsor.
• Campaign content cadence, at least one piece of shadow-AI-in-engineering content published per month.

Effectiveness Metrics (business value)

• Reviewer throughput, intakes closed per reviewer per week should rise after practitioner training lands without sacrificing calibration quality (drift stays in target).
• Sanctioned-archetype adoption, % of new AI/HAI software artifacts using a sanctioned reference archetype rather than a greenfield design; rising reuse signals literacy plus catalog together reducing shadow AI.
• Avoided-incident stories, documented cases where practitioner training enabled a reviewer to catch an AGH, EA, TM, or RA risk at intake that would otherwise have shipped.

Success Criteria

• Workforce AI-assurance literacy module launched; ≥95% current-year completion sustained.
• Practitioner training launched, completion gated on intake-approval permissions, and calibration drift inside target for two consecutive quarters.
• Shadow AI in engineering awareness campaign running with at least monthly content cadence and measurable attribution of intake submissions and amnesty disclosures to campaign channels.
• Deployer-duty micro-content deployed for every customer-facing or decision-affecting AI/HAI archetype active in the inventory.
• Training content owner named; content updated within 30 days of any change to the policies, archetype list, or compliance map.

Maturity Level 2

Objective: Deepen practitioner skill through scenario-based training from real intake cases, deliver product-line-specific engineering tracks calibrated to SM-Software L2 risk tiers, and run seasonal shadow-AI-in-engineering campaigns tied to release cycles

At this level, training stops being one-size-fits-all. Reviewer skill deepens through scenario-based exercises built from anonymized real intakes from the org's own queue. Engineering teams in specific product lines (mobile, web, ML platform, backend services) receive tracks aligned to the archetypes they actually build. Shadow-AI campaigns become behavior-driven and seasonal rather than standing background noise.

Dependencies

• EG-Software L1 (required): workforce literacy and base practitioner training must be in place.
• SM-Software L2 (required): the risk-tier rubric defines which archetypes go to which reviewer track depth and at what cadence.
• TA-Software L2 (required for Critical-tier scenarios): per-artifact deep threat models provide the scenario source material for Critical-tier reviewer exercises.
• Supports / unblocks: PC-Software L2 (tier-calibrated reviewers enforce tier-specific policies and sign-off requirements); SA-Software L2 (engineering-track trainees learn the reference patterns they will build against); DR-Software L2 (scenario-trained reviewers produce faster, more consistent DR decisions).

Desired Outcomes

• Reviewer calibration on Critical-tier intake scenarios is visibly tighter than at L1, the practitioner investment is measurable.
• Product-line engineering teams building mobile, web, ML platform, and backend AI features can independently identify the HAI TTPs relevant to their specific archetype exposure and defend their design choices in a DR.
• Shadow-AI campaigns run on a behavior-driven, seasonal cadence (major release windows, hiring surges, post-external-incident moments) with pre-measured behavior targets and post-campaign measurement.
• Training content refreshes monthly from program telemetry, real calibration drifts, real intake anomalies, real near-incidents, not from annual curriculum reviews.

Activities

A) Scenario-based reviewer training from real intakes

• Scenario library built from anonymized real intakes from the org's own queue: each scenario includes the as-submitted archetype description, the original reviewer decisions (tier, TTP identifications, SR gaps), any reviewer disagreement, and the resolved outcome after calibration or post-launch review.
• Scenarios organized per archetype (agent scenarios, RAG-pipeline scenarios, fine-tune scenarios, model-serving scenarios, etc.) and per TTP cluster (EA-heavy, AGH-heavy, RA-heavy, training-data-leakage-heavy).
• Paired calibration exercises: two reviewers independently score the same scenario; instructor-facilitated debrief on tier delta, TTP identification deltas, and SR gap list differences.
• Tier-weighted curriculum: Critical-tier agent and fine-tune scenarios dominate the advanced modules; Medium/Low scenarios streamlined to fast-track calibration.
• Capstone: practitioners graduate the advanced module by running three live intakes end-to-end with a senior-reviewer shadow and producing a passing TA snapshot and SR REM.

B) Product-line-specific engineering tracks

• Distinct training tracks for engineering product lines building AI/HAI software:
• Mobile track, on-device model serving, RAG with local vector store, agent calls from mobile clients; EA and TM TTPs in mobile surface context; SA reference-pattern differences from server-side.
• Web / SaaS track, LLM-integrated web features, browser-side RAG, customer-facing chatbots; AGH via user-supplied content; Art. 50 transparency in UX; output-integrity in customer-visible responses.
• ML platform track, fine-tuning pipelines, training workloads, model-serving infrastructure, eval harnesses; training-data leakage patterns; no-train verification in provider DPAs; data-egress canary design for prompt/completion logs.
• Backend services track, agentic pipelines calling internal APIs, multi-agent coordination, tool-using backend workers; RA + EA TTP patterns in long-running agent sessions; kill-switch and human-override architecture for server-side agents.
• Each track is paired with the SA reference pattern for the relevant archetype, the training teaches the "green path" the team will implement and defend in DR.
• Required for any team owning a Critical or High-tier artifact in the applicable product line; target ≥1 trained practitioner per artifact.

C) Seasonal, behavior-driven shadow-AI-in-engineering campaigns

• Campaigns tied to observed shadow-AI risk windows in the engineering cycle: major release windows (sprint-to-ship pressure leads to ungated LLM additions), Q1 OKR-planning (teams add AI features to roadmaps without intake), hiring surges (new engineers arrive with pre-existing habits), post-external-incident moments (a public prompt-injection or training-data-leak incident creates a teachable window).
• Each campaign has a pre-measured behavior target (e.g., "reduce ungated LLM SDK imports in the monorepo by 50% in Q3," "increase Critical-tier intake submissions before sprint start by 30%") and a post-campaign measurement.
• Amnesty windows run alongside campaigns; disclosure volume and source attributed to campaign channels.
• Campaign effectiveness reviewed by the program sponsor; campaigns that miss behavior targets by >20% are redesigned.

Outcome Metrics (L2)

Process Metrics (leading)

• Scenario library freshness, scenarios reviewed quarterly; retired when intake patterns make them obsolete.
• Product-line training attendance tracked per artifact in the inventory monthly.
• Campaign pipeline, always ≥1 campaign in-flight tied to a measurable behavior target.
• Calibration debrief findings routed back to the scenario library within 30 days.

Effectiveness Metrics (business value)

• Reduction in intake submissions missing key TTPs or SR gaps at first submission (caught earlier as reviewer skill rises, reviewers coach submitters before they reach the queue).
• Product-line-trained teams' artifacts require fewer DR re-submissions vs. untrained teams.
• Sanctioned-archetype reuse rate for trained product lines rises vs. control group (trained teams reach for the reference pattern; untrained teams invent their own).

Success Criteria

• Scenario library of ≥30 real-sourced scenarios across archetypes in use; reviewer calibration drift inside target for two consecutive quarters.
• Product-line training tracks delivered; ≥1 trained practitioner per Critical/High-tier artifact.
• ≥2 behavior-driven campaigns run in the last 12 months with measured outcomes.
• Training content refresh cadence met; ≥80% of content updated in last 90 days.

Maturity Level 3

Objective: Operate continuous calibration at scale, externalize the AI-assurance curriculum and reviewer rubric as industry-shared artifacts, and contribute to emerging AI-engineering certification pathways

At this level, the organization's training posture is visible outside its own walls. The practitioner curriculum, scenario library, and reviewer rubric are published externally through CSA AI Safety Initiative, OpenSSF AI, OWASP AI security track, or sector ISACs. The program contributes to the emerging AI-engineering and AI-assurance certification pathways as they solidify (CSA AI Safety, ISACA AI, sector-specific credentials). Internally, calibration is continuous and live rather than quarterly.

Dependencies

• EG-Software L2 (required): scenario library, product-line tracks, and behavior-driven campaigns must be in place.
• PC-Software L3 (required for regulatory-track content): continuous attestation and policy-refresh infrastructure provides the real compliance scenarios the external curriculum demonstrates.
• SM-Software L3 (required): automated inventory and tier data feed the continuous calibration exercises with current artifact examples.

Desired Outcomes

• External practitioners recognize and use the program's curriculum and rubric; citations and adoption are tracked.
• Reviewer certification exists (internally aligned with external credentials where credentials have emerged) and is held by a majority of the org's Critical-tier reviewers.
• Monthly live calibration, reviewers re-calibrated against anonymized real intakes from the live queue each month; drift trends are a managed metric.
• Training content evolution is auditable and evidence-driven (telemetry from IM, ML, and DR feeds the curriculum rather than annual scheduled reviews).
• MITRE ATLAS TTPs observed in own-built AI/HAI software are contributed back as new technique candidates or confirmed technique instances.

Activities

A) Externalize the curriculum, scenario library, and reviewer rubric

• Publish the following under a permissive license or as a consortium deliverable through CSA AI Safety Initiative, OpenSSF AI, OWASP AI security track, or applicable sector ISAC (FS-ISAC, H-ISAC, IT-ISAC):
• Workforce AI-assurance literacy module (learning objectives, assessment questions, reference-card template).
• Practitioner role-based training curriculum (module outlines, ATLAS tactic coverage matrix, per-archetype reviewer job aids).
• Anonymized scenario library (scenario format, per-archetype examples, calibration debrief format).
• Reviewer rubric (tier-assignment criteria, TTP-identification scoring, SR-gap-list completeness scoring).
• Community contributions accepted; changes to the external artifact flow back into the internal content within 30 days.
• Adoption tracked: citations in external publications, forks, downloads, direct adoption acknowledgment from other organizations.

B) Continuous live calibration

• Monthly calibration round: a current anonymized intake sampled from the program's live queue is shared with the reviewer cohort; each reviewer independently scores tier, TTPs, and top 3 SR gaps; drift reported to the program sponsor.
• Individual reviewer drift is a development signal, not a performance metric; reviewers with persistent drift on specific archetype types receive targeted coaching and additional scenario exposure.
• Calibration results feed the scenario library directly, new scenarios drawn from intakes where calibration revealed drift are added within 30 days.

C) AI-engineering certification contribution

• Contribute to AI-engineering and AI-assurance certification pathways as they emerge: CSA AI Safety, ISACA AI Audit / AI Risk certificates, sector-specific ISAC credentials, OWASP AI Security curriculum, OpenSSF AI Practitioner path.
• Align the org's practitioner capstone with certification-grade rubrics where credentials exist; support reviewers pursuing external credentials.
• Contribute MITRE ATLAS new-technique candidates and confirmed-technique instances from own-built AI/HAI software observations (minimum 1 per year where novel observations exist).
• Target: ≥2 substantive contributions per year to industry curriculum or certification working groups.

Outcome Metrics (L3)

Process Metrics (leading)

• Curriculum refresh pipeline: ≥1 change per quarter driven by IM/ML telemetry or external update.
• Reviewer certification pathway participation tracked per reviewer.
• External outreach: ≥2 conference or working-group engagements per year on AI-assurance education topics.
• Calibration debrief findings fed to scenario library within 30 days.

Effectiveness Metrics (business value)

• Talent acquisition, the program is a named draw for practitioner-track hires and for engineering teams that want to build AI securely.
• Reduced on-boarding time for new reviewers who arrive with external credentials.
• Industry recognition, program cited by regulators, standards bodies, or peer organizations as reference for AI-assurance education.
• Internal re-submission rate for intakes continues to decline as external curriculum adoption provides pre-trained practitioners from outside the org.

Success Criteria

• Curriculum, scenario library, and reviewer rubric published externally with documented adoption.
• Monthly live calibration operating; drift inside target for two consecutive quarters.
• ≥50% of Critical-tier reviewers credentialed (where credentials exist).
• ≥2 substantive contributions to industry certification / curriculum per year.
• ≥1 MITRE ATLAS TTP contribution or confirmation per year where novel observations exist.

Key Success Indicators

Level 1: - Workforce AI-assurance literacy module launched; ≥95% current-year completion across engineers building AI/HAI software; content tied to the AI AUP attestation. - Practitioner role-based training launched, gated on intake-approval permissions, covering ATLAS tactics, OWASP LLM / Agentic Top 10, prompt injection, agent goal hijack, tool misuse, training-data poisoning, output-integrity testing, and kill-switch design. - Reviewer calibration drift inside target (≤1 tier step and ≤2 TTP misclassifications per sample) for two consecutive quarters. - Shadow-AI-in-engineering awareness campaign running with monthly content cadence; amnesty disclosures attributable to campaign channels rising in Q1–Q2 then declining as the sanctioned-archetype catalog grows. - Training content owner named; content updated within 30 days of any change to policies, archetypes, or compliance map.

Level 2: - Scenario library of ≥30 anonymized real-sourced intakes powering reviewer training across archetypes; Critical-tier calibration drift inside target. - Product-line-specific engineering tracks (mobile, web, ML platform, backend) delivered; ≥1 trained practitioner per Critical/High-tier artifact. - ≥2 behavior-driven shadow-AI campaigns run in the last 12 months with measured outcomes; ≥70% of campaigns hit pre-set behavior target. - Training content refreshed in last 90 days for ≥80% of modules.

Level 3: - Curriculum, scenario library, and reviewer rubric published externally (CSA / OpenSSF AI / OWASP AI / sector ISAC) with documented adoption or citation. - ≥50% of Critical-tier reviewers hold an external AI-assurance or AI-engineering credential (where one exists). - Monthly live calibration operating with drift inside target; calibration results feeding the scenario library continuously. - ≥2 substantive contributions to industry AI-engineering certification or curriculum working groups per year; ≥1 MITRE ATLAS contribution or confirmation per year where novel observations exist.

Common Pitfalls

Level 1: - ❌ Workforce training covers classic OWASP Top 10 but not the HAI TTPs (EA / AGH / TM / RA), engineers know about SQL injection but not about agent goal hijack or excessive agency; the AI-specific gap remains open. - ❌ Practitioner training is a one-hour "intro to LLMs" rather than a hands-on module covering ATLAS tactics, OWASP LLM / Agentic Top 10, and TTP-recognition exercises against real archetype examples. - ❌ Reviewer training is optional, intake-approval permissions granted without training completion; calibration drift is never measured; two reviewers regularly arrive at different tiers for the same archetype. - ❌ Shadow-AI campaign launches once with an exec message, then goes silent, no monthly content, no amnesty attribution, no feedback channel; engineers never hear about it again. - ❌ Training is archetype-agnostic, "AI security" without distinguishing between an agent (AGH / EA / TM / RA all apply) and a classical ML classifier (training-data poisoning applies; AGH does not); practitioners apply the wrong threat lens. - ❌ Deployer-duty micro-content never ships for customer-facing features, engineers shipping AI product features have no mental model for Art. 26 human oversight or Art. 50 disclosure obligations at the code level. - ❌ Training content owner is unnamed, content goes stale within a quarter; engineers find outdated AUP references and stop trusting the module.

Level 2: - ❌ Scenario library is built from invented examples rather than anonymized real intakes, reviewers learn the shape of a "good" intake but not the actual edge cases that surface in the org's queue. - ❌ Product-line tracks are optional; engineering teams skip them and then produce designs in DR that do not account for archetype-specific TTPs; DR catches the gaps late and at high cost. - ❌ Campaigns are launched without a pre-measured behavior target, "shadow AI awareness" claimed as a success without data on whether ungated LLM imports decreased or amnesty disclosures increased. - ❌ Content "refreshes" are cosmetic, module covers get updated, scenario descriptions get wordsmithed, but the TTP library and calibration rubric go stale while real intake patterns change. - ❌ Calibration drift is measured but not acted on, reviewers with persistent drift never receive coaching; the calibration exercise becomes a box-check rather than a development signal.

Level 3: - ❌ External publication without ongoing maintenance, other organizations find a stale scenario library and stop trusting the program; citations dry up. - ❌ Credentialing becomes performative, reviewers pursue credentials that do not map to the org's actual tier-treatment rubric; credential acquisition is celebrated but calibration drift stays unchanged. - ❌ Live calibration becomes a gotcha rather than a development signal, reviewers learn to game the monthly exercise and improve their calibration scores without improving their actual intake quality. - ❌ Contributions to industry working groups do not loop back, what is published externally drifts from what reviewers use internally; practitioners cite the external artifact and contradict the internal rubric. - ❌ ATLAS contributions are aspirational ("we plan to contribute") but never actually submitted, the org observes novel TTPs in own-built agents but does not complete the ATLAS submission process.

Practice Maturity Questions

Level 1: 1. Have all engineers building or operating AI/HAI software completed a current-year AI-assurance literacy course covering the seven in-scope archetypes, the four HAI TTPs (EA / AGH / TM / RA) plus prompt injection / training-data leakage / output-integrity regression, the AI AUP rules, and the go-live gate intake process, with ≥95% completion and content updated within 30 days of any policy or archetype change? 2. Has the practitioner population (AppSec reviewers, AI/ML platform engineers, AI-feature architects, red-teamers) completed role-based training covering ATLAS tactics, OWASP LLM / Agentic Top 10, prompt injection patterns, agent goal hijack, tool misuse, training-data poisoning, output-integrity testing, and kill-switch design, with completion gated on intake-approval permissions and calibration drift ≤1 tier step and ≤2 TTP misclassifications per sample for two consecutive quarters? 3. Is a shadow-AI-in-engineering awareness campaign running with at least monthly content, a visible amnesty path linked from the AUP and intake form, and measurable attribution of intake submissions and amnesty disclosures to campaign channels, with disclosures rising in Q1–Q2 after launch then declining as the sanctioned-archetype program grows?

Level 2: 1. Is there a scenario library of ≥30 anonymized real intake cases powering practitioner training across the org's in-scope archetypes, with paired calibration exercises showing Critical-tier drift ≤1 tier step and ≤1 TTP misclassification per sample for two consecutive quarters? 2. Have product-line-specific engineering tracks (covering the relevant archetypes and SA reference patterns for mobile, web, ML platform, and backend as applicable) been delivered to ≥1 practitioner per Critical/High-tier artifact, with team-level training coverage tracked in the SM-Software inventory? 3. Are shadow-AI campaigns running on a seasonal, behavior-driven cadence with pre-set behavior targets (not just "awareness") and post-campaign measurement, and is ≥70% of campaigns hitting their target, and is ≥80% of training content updated in the last 90 days?

Level 3: 1. Has the practitioner curriculum, anonymized scenario library, and reviewer rubric been published externally (CSA, OpenSSF AI, OWASP AI, or sector ISAC) with documented adoption, citations, forks, or direct acknowledgment, and do contributions loop back into internal content within 30 days? 2. Is a monthly live calibration cadence operating (anonymized intake from the live queue, independent reviewer scoring, drift reported to sponsor), with calibration results feeding the scenario library within 30 days, and do ≥50% of Critical-tier reviewers hold an external AI-assurance or AI-engineering credential where one exists? 3. Does the program contribute ≥2 substantive artifacts per year to industry AI-engineering certification or curriculum working groups, and ≥1 MITRE ATLAS TTP contribution or confirmation per year where novel observations exist in own-built AI/HAI software?

Document Version: HAIAMM v3.0 Practice: Education & Guidance (EG) Domain: Software Last Updated: 2026-05-13 Author: Verifhai