Education & Guidance (EG)

Infrastructure Domain - HAIAMM v3.5

Generated from the canonical cell records in cells/. Do not edit by hand; edit cells/EG-Infrastructure-L*.cell.json and re-run tools/render.py.

---

Practice Overview

Business Function: Governance

Objective: Give the people who provision and operate AI infrastructure the role-based AI security literacy and the practical guidance they need to make safe decisions without asking, in the Infrastructure domain.

Description: A program at this level has stopped relying on general security awareness to cover AI-specific risk. Role-based training reaches platform and site-reliability engineers, cloud architects, ML platform engineers, and the security architects reviewing their baselines, and it teaches the failure modes those roles actually encounter rather than a survey of AI risk in general. A guidance library sits where the work happens, so the answer to a routine question is reachable in under a minute rather than requiring a security consultation. Competence is assessed rather than assumed, because completion rates measure attendance and say nothing about whether anyone can now do the thing.

---

Maturity Level 1, Foundational

Objective: Give the people who provision and operate AI infrastructure the role-based AI security literacy and the practical guidance they need to make safe decisions without asking, in the Infrastructure domain.

A program at this level has stopped relying on general security awareness to cover AI-specific risk. Role-based training reaches platform and site-reliability engineers, cloud architects, ML platform engineers, and the security architects reviewing their baselines, and it teaches the failure modes those roles actually encounter rather than a survey of AI risk in general. A guidance library sits where the work happens, so the answer to a routine question is reachable in under a minute rather than requiring a security consultation. Competence is assessed rather than assumed, because completion rates measure attendance and say nothing about whether anyone can now do the thing.

Dependencies

• Required: SM-Infrastructure-L1, PC-Infrastructure-L1
• Alignment (not blocking): Existing security awareness and technical training programs, so AI content extends an established delivery channel rather than competing with it
• Supports / unblocks: TA-Infrastructure-L1; SR-Infrastructure-L1; SA-Infrastructure-L1; IR-Infrastructure-L1; DR-Infrastructure-L1; Required by: EG-Infrastructure-L2

Desired Outcomes

• Every role in scope has training matched to the AI failure modes that role actually encounters in the Infrastructure domain.
• Competence is assessed rather than inferred from attendance, so the programme knows what people can do rather than what they attended.
• A guidance library answers routine questions in under a minute, at the point where the work happens.
• People know how to ask for help on an AI security question and who will answer it.
• New joiners in scope reach baseline literacy within their first 90 days.

Activities

A) Define roles and build role-based curricula

Identify the roles in scope, being platform and site-reliability engineers, cloud architects, ML platform engineers, and the security architects reviewing their baselines, and build a short curriculum per role rather than one course for everyone. A single general course is the most common failure in this practice: it is long enough to be resented, general enough to be forgettable, and calibrated to no one. Each curriculum covers the AI failure modes that role actually meets, which in this domain means unsanctioned model hosting, standing credentials on accelerator fleets, inference endpoints exposed beyond their intended boundary, and denial-of-wallet at the serving layer, together with the specific controls that role is expected to apply and the escalation path when something looks wrong. Keep each curriculum under 90 minutes, because attention is the binding constraint and a curriculum nobody finishes teaches nothing. Set a 90-day competence deadline for new joiners in scope, and deliver through the existing learning system so that completion and assessment records land where compliance evidence already lives.

B) Assess competence rather than completion

Build an assessment per role that tests whether the learner can apply the material, not whether they sat through it. Include a hands-on exercise where the learner exposes an inference endpoint, observes the absence of any availability signal under a wallet-drain load, and then applies per-tenant limits, because a scenario the learner works through is the only assessment format that distinguishes recognition from capability, and recognition is what multiple-choice tests measure. Set a pass threshold, require a retake on failure, and record the pass rate per role as the practice's headline outcome metric. Publish item-level results to the curriculum owner so that a question the whole cohort fails is treated as a teaching failure rather than a learner failure, which is the usual cause. Re-assess at least annually and whenever the threat picture or the sanctioned toolset changes materially.

C) Publish the guidance library where the work happens

Publish a guidance library covering hardened infrastructure-as-code modules for serving, registry and vector-store deployment, with egress allowlisting and no-standing-access identity patterns. The binding constraint is reachability, not completeness: guidance that requires leaving the working context to find will be guessed around, so place it where the work is, in the repository for engineers, in the workflow tool for process owners, in the service catalogue for requesters. Every guidance item names an owner and a review date, and stale guidance is withdrawn rather than left standing, because out-of-date guidance is worse than none and is trusted for longer. Publish a named route for questions the library does not answer, staffed with a response service level, and mine those questions monthly as the highest-quality signal available about where the guidance is missing or wrong.

Outcome Metrics (L1)

Metric	Baseline	L1 Target	Source
In-scope practitioners passing the role-based AI security assessment	first assessment round	≥80% pass rate per role, with per-role results reported	Learning system assessment records; where no learning system is in use, a dated completion and assessment register held by the practice lead, recorded at E1
In-scope roles with a published curriculum matched to their actual failure modes	first curriculum build	100% of identified roles	Curriculum register
New joiners in scope reaching baseline literacy within 90 days	first cohort	≥90%	Learning system completion records joined to HR start dates; where no learning system is in use, a dated completion and assessment register held by the practice lead, recorded at E1
Guidance library items carrying a named owner and a review date within the last 12 months	first library audit	100%, with stale items withdrawn rather than retained	Guidance library metadata
Questions to the named route answered within the published service level	first quarter of question telemetry	≥90% within 5 business days	Question route ticket log

Process Metrics (leading)

• Curricula reviewed at least annually and on material change to the threat picture or sanctioned toolset.
• Assessment item-level results reviewed by the curriculum owner each cycle, with cohort-wide failures treated as teaching defects.
• Guidance questions mined monthly for gaps, with resulting library updates tracked.
• New-joiner enrolment triggered automatically from the HR joiner process rather than manually.

Effectiveness Metrics (business value)

• Security consultations for routine questions fall as the guidance library covers them, freeing reviewer time for genuine design questions.
• Findings in downstream practices attributable to a knowledge gap fall, reported by category.
• Time for a new joiner in scope to first sanctioned AI contribution falls.

Level of Effort (incremental over the level below)

• Stand-up: 160 hours · Ongoing: 60 hours/quarter
• Program Manager / Practice Lead — primary, 24 days/year
• Security Architect — regular, 12 days/year
• AppSec / SecEng — regular, 10 days/year
• Business Owner / PM — low, 5 days/year
• Material new tooling: Existing learning management system, extended with applied-scenario assessment

Success Criteria

• Every in-scope role among platform and site-reliability engineers, cloud architects, ML platform engineers, and the security architects reviewing their baselines has a curriculum under 90 minutes covering the failure modes that role actually encounters.
• Competence is assessed by applied scenario rather than recall, with an 80% or better pass rate per role and per-role results published.
• New joiners in scope reach baseline literacy within 90 days, enrolled automatically from the joiner process.
• A guidance library sits where the work happens, with every item carrying an owner and a review date and stale items withdrawn.
• A named question route operates with a published response service level and is mined monthly for guidance gaps.

---

Maturity Level 2, Comprehensive

Objective: Scale Infrastructure AI security literacy through tier-calibrated depth, a champions network embedded in the teams, and exercises drawn from the organisation's own incidents.

At this level education stops being uniform and starts being proportionate. Practitioners working on Critical-tier assets receive deeper, hands-on training than those working on Low-tier ones, and the difference is published. A champions network embeds a trained person inside each team, which is what converts a central function into distributed capability and is the single highest-leverage structure available to this practice. Exercises are drawn from the organisation's own incidents and near-misses rather than from generic examples, because a scenario a team recognises is a scenario it remembers.

Dependencies

• Required: EG-Infrastructure-L1, SM-Infrastructure-L2, IM-Infrastructure-L1
• Alignment (not blocking): Engineering and business management chains, since champion time must be explicitly allocated rather than volunteered
• Supports / unblocks: TA-Infrastructure-L2; SA-Infrastructure-L2; DR-Infrastructure-L2; IR-Infrastructure-L2; ST-Infrastructure-L2; Required by: EG-Infrastructure-L3, SM-Infrastructure-L3

Desired Outcomes

• Training depth is proportionate to the tier of the assets the practitioner works on, and the difference is published.
• Each team working on Critical- and High-tier assets has a trained champion with allocated time.
• Exercises are drawn from the organisation's own incidents and near-misses rather than from generic examples.
• Champions are the first line for routine questions, and the central function handles only what they escalate.
• The programme knows which teams are strong and which are weak, per tier, rather than knowing an organisation-wide average.

Activities

A) Calibrate curriculum depth to asset tier

Extend the L1 curricula with tier-calibrated depth keyed to the SM L2 rubric. Practitioners working on Critical- and High-tier assets take an extended curriculum with hands-on laboratory work and a higher pass threshold; those on Medium and Low take the baseline. Publish the mapping from asset tier to required curriculum so that assignment is derived rather than negotiated, and wire enrolment to the asset inventory so that a practitioner joining a Critical-tier team is enrolled automatically rather than when someone remembers. Set a currency requirement: Critical-tier practitioners re-assess annually, others every two years. Report pass rates and currency by tier rather than in aggregate, because an organisation-wide 85% pass rate is consistent with the Critical-tier cohort being the weakest, and aggregate reporting actively conceals exactly the case that matters. In this domain the extended curriculum has learners expose an inference endpoint, drive a wallet-drain load against it, and observe that every availability dashboard stays green throughout, because that observation changes how platform engineers think about limits far more effectively than a policy does.

B) Build and resource a champions network

Establish a security champion inside each team working on Critical- and High-tier assets. The champion is not a security professional and should not be treated as one: the role is to be the person who recognises when something needs the central function, to answer the routine questions locally, and to carry context the central team cannot have. Resource the role explicitly with allocated time, typically half a day a week, agreed with the engineering or business management chain rather than assumed as goodwill, because an unresourced champion network decays within two quarters and its decay is invisible until it is total. Give champions a deeper curriculum, a private channel to the central team, early access to threat and guidance updates, and visible recognition in performance processes. Meet the network monthly and mine it for what the central function cannot see. Infrastructure champions sit inside the platform and site-reliability teams, and their distinguishing value is knowing which workload just requested accelerators and why, which cost allocation reveals only a billing cycle later.

C) Run exercises from the organisation's own incidents

Convert incidents and near-misses from the issue-management practice into teaching material on a defined cadence, targeting one new exercise per quarter. An exercise built from something that actually happened in this organisation carries an authority that no generic example achieves, and it converts the incident from a cost into an asset. Anonymise where necessary but keep the specifics that make it recognisable, since the recognisable detail is the part that is remembered. Run the exercises with the champions network first, then let champions run them with their teams, which both scales delivery and tests whether the champion can teach the material rather than only pass an assessment. Track which failure modes recur across exercises and feed that back to the threat assessment and guidance practices as evidence of where understanding is genuinely weak. Infrastructure exercises are built from real exposure incidents and shadow-workload discoveries, where the recognisable detail is usually a security group or namespace the team recognises.

Outcome Metrics (L2)

Metric	Baseline	L2 Target	Source
Practitioners on Critical- and High-tier assets holding a current extended-curriculum pass	first tier-calibrated round	≥90% of Critical-tier practitioners, ≥80% of High	Learning records joined to the asset inventory tier
Teams working on Critical- and High-tier assets with a trained champion holding allocated time	first champion round	100% of Critical-tier teams, ≥85% of High	Champion register with management-agreed time allocation
Assessment pass rate reported per tier rather than in aggregate	L1 aggregate pass rate	≥85% at every tier, with no tier below the organisation average by more than 5 points	Learning records segmented by tier
Exercises drawn from the organisation's own incidents	0	≥4 per year, each traced to a specific incident or near-miss	Exercise register joined to the issue tracker
Routine AI security questions resolved by a champion without central escalation	first quarter of routing telemetry	≥60%	Question route ticket log with resolver field

Process Metrics (leading)

• Enrolment triggered automatically from the asset inventory when a practitioner joins a Critical- or High-tier team.
• Champions network meets monthly, with attendance and allocated-time conformance tracked.
• One new exercise built from a real incident each quarter.
• Currency tracked continuously, with re-assessment triggered before expiry rather than after.

Effectiveness Metrics (business value)

• Central function time spent on routine questions falls as champions absorb them, freeing capacity for design review.
• Findings attributable to a knowledge gap fall fastest in teams with an active champion, reported comparatively.
• Recurring failure modes across exercises fall over time, which is the honest measure that the teaching is working.
• Champion retention, since a network that cannot retain champions is not resourced.

Level of Effort (incremental over the level below)

• Stand-up: 140 hours · Ongoing: 110 hours/quarter
• Program Manager / Practice Lead — primary, 26 days/year
• Security Architect — regular, 16 days/year
• AppSec / SecEng — regular, 14 days/year
• Security Analyst / SOC — low, 6 days/year
• Executive Sponsor — low, 2 days/year
• Material new tooling: Hands-on laboratory environment for Critical-tier curricula

Success Criteria

• Curriculum depth is calibrated to asset tier with enrolment derived from the inventory, and pass rates are reported per tier rather than in aggregate.
• Every team working on Critical-tier assets has a trained champion with management-agreed allocated time.
• At least four exercises per year are built from the organisation's own incidents and near-misses.
• Champions resolve at least 60% of routine questions without central escalation.
• Recurring failure modes across exercises are fed back to threat assessment and guidance as evidence of genuine weakness.

---

Maturity Level 3, Industry-Leading

Objective: Make Infrastructure AI security learning continuous and evidence-driven, measure whether it changes behaviour rather than knowledge, and contribute curricula back to the field.

At this level learning is driven by what the organisation observes rather than by an annual calendar. Guidance and curricula update from incident patterns, review findings and telemetry, so the material tracks the threat picture rather than lagging it by a planning cycle. The programme measures behaviour change rather than assessment scores, which is a harder measurement and the only one that matters. Curricula and exercise material are contributed back to the field, which is unusually valuable in AI security because the shortage of good teaching material is the field's binding constraint.

Dependencies

• Required: EG-Infrastructure-L2, IM-Infrastructure-L2, ML-Infrastructure-L2
• Alignment (not blocking): Talent and performance management, so demonstrated AI security capability is recognised in career progression
• Supports / unblocks: Every other Infrastructure practice at L3, which depends on the practitioner capability this cell sustains

Desired Outcomes

• Curricula and guidance update from observed incidents, findings and telemetry rather than on an annual calendar.
• The programme measures behaviour change in the environment rather than assessment scores alone.
• Demonstrated AI security capability is recognised in performance and progression processes.
• Curricula and exercise material are contributed back to the field, where good teaching material is scarce.
• Guidance gaps are detected from what practitioners actually search for and ask, not from periodic review alone.

Activities

A) Drive curriculum and guidance from observed signal

Close the loop between what the organisation observes and what it teaches. Feed incident root causes, design and implementation review findings, security test failures and monitoring detections into a quarterly curriculum review, and treat any failure mode appearing three times as a mandatory curriculum change rather than a discussion item. Instrument the guidance library so that search terms returning nothing, and the questions reaching the named route, are captured as gap signals, because what practitioners look for and fail to find is the highest-quality guidance-gap data available and it is free. Publish a service level covering the interval from an observed recurring failure mode to updated guidance, targeting 30 days. Retire material that the signal shows is no longer relevant, since a curriculum that only grows becomes one nobody completes. In this domain the extended curriculum has learners expose an inference endpoint, drive a wallet-drain load against it, and observe that every availability dashboard stays green throughout, because that observation changes how platform engineers think about limits far more effectively than a policy does.

B) Measure behaviour change rather than knowledge

Move the headline measure from assessment scores to behaviour in the environment. Compare teams and cohorts before and after training on measures the other practices already produce: the rate of findings by category in implementation review, the reuse rate of sanctioned patterns, the proportion of designs arriving at review already conformant, the rate of self-reported near-misses, which should rise as psychological safety improves and is one of the few metrics where an increase is good news. Accept that attribution is imperfect and say so, rather than claiming a causal link the data cannot carry; the honest claim is that behaviour moved in the trained cohort and did not in the untrained one, over a stated period. Report behaviour measures alongside assessment results so that a high pass rate with unchanged behaviour is visible as the failure it represents. Infrastructure champions sit inside the platform and site-reliability teams, and their distinguishing value is knowing which workload just requested accelerators and why, which cost allocation reveals only a billing cycle later.

C) Contribute curricula and measure capability in progression

Contribute at least four substantive artifacts per year to the field, weighted toward teaching material: role-based AI security curricula, applied exercise and laboratory scenarios, anonymised incident case studies that other organisations can teach from, and guidance patterns. Good AI security teaching material is the field's scarcest resource, far scarcer than frameworks or tooling, which makes curriculum contribution unusually high-leverage and unusually likely to be adopted. Work through OWASP education projects, sector bodies, professional associations and academic partnerships. Separately, establish AI security capability as a recognised factor in performance and progression for in-scope roles, agreed with human resources, because a capability the organisation says matters but never recognises is one practitioners correctly deprioritise. Infrastructure exercises are built from real exposure incidents and shadow-workload discoveries, where the recognisable detail is usually a security group or namespace the team recognises.

Outcome Metrics (L3)

Metric	Baseline	L3 Target	Source
Recurring failure modes reaching updated guidance within the service level	first quarter of loop telemetry	≥90% within 30 days of the third occurrence	Guidance change log joined to the issue tracker
Guidance gap signals captured from search misses and unanswered questions	0	captured continuously, with ≥80% triaged within 30 days	Guidance search telemetry and question route log
Behaviour change measured in the environment for trained cohorts	0	≥3 behaviour measures tracked pre and post training, reported with attribution limits stated	Downstream practice telemetry segmented by cohort
Externally accepted curriculum and exercise contributions per year	0	≥4 accepted or published	Contribution log with acceptance references
In-scope roles with AI security capability recognised in performance and progression criteria	0	100% of in-scope roles, agreed with human resources	Published role and progression criteria

Process Metrics (leading)

• Quarterly curriculum review driven by incident, finding, test and detection signal.
• Guidance search-miss and question telemetry triaged at least monthly.
• Material retired as well as added, with the curriculum length tracked so it does not only grow.
• Contribution pipeline carries at least two artifacts in draft or external review.

Effectiveness Metrics (business value)

• Findings by category fall faster in trained cohorts than untrained ones over a stated period, with attribution limits acknowledged.
• Self-reported near-misses rise, which indicates improving psychological safety rather than worsening security.
• Retention and internal mobility improve for in-scope roles where capability is recognised in progression.
• External adoption of contributed curricula and exercises by peer organisations.

Level of Effort (incremental over the level below)

• Stand-up: 180 hours · Ongoing: 80 hours/quarter
• Program Manager / Practice Lead — primary, 22 days/year
• Security Architect — regular, 14 days/year
• AppSec / SecEng — regular, 12 days/year
• Compliance / Audit — low, 4 days/year
• Material new tooling: Guidance search and question telemetry instrumentation

Success Criteria

• Curricula and guidance update from observed incidents, findings and telemetry, with recurring failure modes reaching updated guidance within 30 days.
• Guidance gaps are detected from search misses and unanswered questions rather than from periodic review alone.
• At least three behaviour measures are tracked pre and post training, reported alongside assessment results with attribution limits stated.
• At least four externally accepted curriculum or exercise contributions per year.
• AI security capability is a recognised factor in performance and progression for every in-scope role, agreed with human resources.

---

Key Success Indicators

Level 1:

• Every in-scope role among platform and site-reliability engineers, cloud architects, ML platform engineers, and the security architects reviewing their baselines has a curriculum under 90 minutes covering the failure modes that role actually encounters.
• Competence is assessed by applied scenario rather than recall, with an 80% or better pass rate per role and per-role results published.
• New joiners in scope reach baseline literacy within 90 days, enrolled automatically from the joiner process.
• A guidance library sits where the work happens, with every item carrying an owner and a review date and stale items withdrawn.
• A named question route operates with a published response service level and is mined monthly for guidance gaps.

Level 2:

• Curriculum depth is calibrated to asset tier with enrolment derived from the inventory, and pass rates are reported per tier rather than in aggregate.
• Every team working on Critical-tier assets has a trained champion with management-agreed allocated time.
• At least four exercises per year are built from the organisation's own incidents and near-misses.
• Champions resolve at least 60% of routine questions without central escalation.
• Recurring failure modes across exercises are fed back to threat assessment and guidance as evidence of genuine weakness.

Level 3:

• Curricula and guidance update from observed incidents, findings and telemetry, with recurring failure modes reaching updated guidance within 30 days.
• Guidance gaps are detected from search misses and unanswered questions rather than from periodic review alone.
• At least three behaviour measures are tracked pre and post training, reported alongside assessment results with attribution limits stated.
• At least four externally accepted curriculum or exercise contributions per year.
• AI security capability is a recognised factor in performance and progression for every in-scope role, agreed with human resources.

---

Common Pitfalls

Level 1:

• ❌ Building one general AI security course for everyone, which is too long to finish, too general to apply, and calibrated to no actual role.
• ❌ Measuring completion rather than competence, which tells the programme who attended and nothing about what anyone can now do.
• ❌ Publishing guidance in a wiki nobody opens, when reachability from the working context is the whole of the control.
• ❌ Leaving stale guidance standing, which is worse than no guidance because it is trusted for longer.
• ❌ Treating cohort-wide assessment failures as a learner problem rather than as evidence the material taught the wrong thing.

Level 2:

• ❌ Reporting one organisation-wide pass rate, which is consistent with the Critical-tier cohort being the weakest and conceals precisely that case.
• ❌ Appointing champions without allocated time, after which the network decays within two quarters and its decay is invisible until total.
• ❌ Treating champions as junior security staff rather than as embedded context-holders, which drives away the people best suited to the role.
• ❌ Using generic exercise material when the organisation's own incidents are available, discarding the authority that recognisable detail carries.
• ❌ Anonymising exercises so thoroughly that the recognisable specifics are gone, which removes the part learners actually remember.

Level 3:

• ❌ Reviewing curricula annually while the threat picture moves quarterly, so the material lags by a planning cycle permanently.
• ❌ Adding material without ever retiring any, producing a curriculum too long to complete and therefore completed by nobody.
• ❌ Claiming training caused a behaviour improvement when the data supports only correlation, which discredits the honest measures alongside it.
• ❌ Ignoring search misses and unanswered questions, which are the cheapest and highest-quality guidance-gap signal available.
• ❌ Declaring AI security capability important while never recognising it in progression, which practitioners correctly read as a statement of priority.

---

Practice Maturity Questions

Level 1:

1. Does every in-scope role have its own curriculum under 90 minutes covering the AI failure modes that role actually encounters in the Infrastructure domain, delivered through the existing learning system with a 90-day deadline for new joiners?
2. Is competence assessed by applied scenario rather than recall, with a published pass threshold, an 80% or better pass rate per role, and item-level results reviewed by the curriculum owner so cohort-wide failures are treated as teaching defects? For Infrastructure, the assessor should be shown the platform-engineer curriculum and the wallet-drain exercise.
3. Does a guidance library sit where the work happens with every item carrying an owner and a review date, are stale items withdrawn rather than retained, and is there a named question route with a response service level that is mined monthly for gaps? In Infrastructure, ask to see the platform-engineer curriculum and the wallet-drain exercise.

Level 2:

1. Is curriculum depth calibrated to the SM L2 asset tier with enrolment derived automatically from the inventory, and are pass rates and currency reported per tier rather than in an aggregate that could conceal a weak Critical-tier cohort? Evidence this in the Infrastructure domain against the platform-engineer curriculum and the wallet-drain exercise.
2. Does every team working on Critical-tier assets have a trained champion with explicitly allocated time agreed with the management chain, and do champions resolve at least 60% of routine questions without central escalation? For Infrastructure, the assessor should be shown the platform-engineer curriculum and the wallet-drain exercise.
3. Are at least four exercises per year built from the organisation's own incidents and near-misses, run first with champions and then by champions with their teams, with recurring failure modes fed back to threat assessment and guidance? In Infrastructure, ask to see the platform-engineer curriculum and the wallet-drain exercise.

Level 3:

1. Do curricula and guidance update from incident root causes, review findings, test failures and detections, with any failure mode appearing three times triggering a mandatory curriculum change within 30 days, and are guidance gaps detected from search misses and unanswered questions? Evidence this in the Infrastructure domain against the platform-engineer curriculum and the wallet-drain exercise.
2. Does the programme measure behaviour change in the environment using at least three downstream measures tracked pre and post training, reported alongside assessment results with attribution limits stated rather than a causal claim the data cannot carry? For Infrastructure, the assessor should be shown the platform-engineer curriculum and the wallet-drain exercise.
3. Does the organisation contribute at least four externally accepted curriculum or exercise artifacts per year, and is AI security capability a recognised factor in performance and progression for every in-scope role? In Infrastructure, ask to see the platform-engineer curriculum and the wallet-drain exercise.

---

Lightweight Questions (E0 rung)

Answerable yes/no by one person in under 30 seconds, with nothing open.

Level 1:

• Does anyone in the people get AI-specific security training?
• Can someone find guidance on a routine AI security question in under a minute?
• Do you know who answers an AI security question when guidance runs out?

Level 2:

• Do people working on your riskiest AI get deeper training than everyone else?
• Does each team working on high-risk AI have a named security champion?
• Has any training exercise been built from an incident that actually happened here?

Level 3:

• Does your training change when an incident reveals a new failure mode?
• Do you measure whether training changed behaviour, or only test scores?
• Have you published AI security teaching material externally?

---

Tracking

Level 1 — Jira Epic, labels haiamm-eg-infrastructure-l1, haiamm-governance

• Done when: Role-based assessment pass rate at or above 80% for every in-scope role with full curriculum coverage and zero guidance items past their review date, sustained two consecutive quarters.
• Git artifacts: education/infrastructure/, education/curriculum-register.json, education/guidance-index.json
• Git signal: guidance-index.json carries an owner and review date per item and is checked by CI for entries past review, and curriculum files carry a commit within their annual review interval.
• CI check: guidance-freshness-check

Level 2 — Jira Epic, labels haiamm-eg-infrastructure-l2, haiamm-governance

• Done when: Critical-tier practitioner currency at or above 90% with every Critical-tier team holding a resourced champion and at least four incident-derived exercises in the trailing year, sustained two quarters.
• Git artifacts: education/champion-register.json, education/exercise-register.json, education/infrastructure/
• Git signal: champion-register.json records a management-agreed time allocation per champion, and exercise-register.json links each exercise to the issue-tracker record of the incident it was built from.
• CI check: champion-allocation-audit

Level 3 — Jira Epic, labels haiamm-eg-infrastructure-l3, haiamm-governance

• Done when: Recurring failure modes reaching updated guidance within 30 days at or above 90%, with at least three behaviour measures tracked pre and post training, sustained across two consecutive quarters.
• Git artifacts: education/guidance-change-log.json, education/behaviour-measures.json, governance/contribution-log.json
• Git signal: guidance-change-log.json links each change to the incident, finding or detection that triggered it, and behaviour-measures.json is regenerated from downstream practice telemetry rather than hand-maintained.
• CI check: guidance-loop-sla

---

Mappings

Level	HAI TTP	ATLAS	OWASP LLM 2025	Compliance
L1	EA, TM	AML.T0035, AML.T0044, AML.T0049, AML.T0055	LLM03, LLM10	EU AI Act Art. 4; EU AI Act Art. 26; ISO/IEC 42001 7.2; NIST AI RMF GOVERN 2.2; ISO/IEC 27001 A.6.3
L2	EA, TM	AML.T0035, AML.T0044, AML.T0049, AML.T0055	LLM03, LLM10	EU AI Act Art. 4; ISO/IEC 42001 7.2; ISO/IEC 42001 7.3; NIST AI RMF GOVERN 2.2; NIST AI RMF GOVERN 4.1
L3	EA, TM	AML.T0035, AML.T0044, AML.T0049, AML.T0055	LLM03, LLM10	EU AI Act Art. 4; ISO/IEC 42001 7.2; ISO/IEC 42001 9.1; NIST AI RMF GOVERN 2.2; NIST AI RMF MEASURE 2.8

---

Document Version: HAIAMM v3.5 (generated) / Practice: Education & Guidance (EG) / Domain: Infrastructure