Planning the AIMS

Lesson 2 of 5 in Lead Implementer Track: Building an AIMS from Mandate to Certificate.

The aims-42001 module taught you what clauses 4–6 require; this lesson is about producing artifacts that do the job. The difference between a planning set that sails through Stage 2 and one that burns is rarely a missing document — it is whether the documents trace to your organisation or could belong to anyone.

Context (clause 4) is fieldwork, not a form. Run it as structured workshops with the people who actually touch AI: an issues list that names real things — the pending EU AI Act deadlines that bind you, the single vendor your flagship product depends on, the skills gap in the data team — not generic PESTLE filler. The interested-party register must include AI subjects: the applicants your models score, the patients your system triages. They never attend workshops, so someone must be assigned to represent their interests — that assignment is what makes the 6.1.4 impact assessment later possible.

Leadership artifacts (clause 5) are written for use, not for shelf. The working test for an AI policy: could a new hire read it and infer what is forbidden, what needs approval, and who decides? If not, it frames nothing and clause 6 has nothing to hang from. Pair it with a RACI that names a person — not a committee — as accountable for AIMS conformity and another for reporting its performance upward.

Planning artifacts: what good looks like — and the smell that predicts a finding
Artifact	What good looks like	The smell auditors catch
Context analysis	Names specific regulations, dependencies, and capability gaps; dated; revisited when the world moves	Generic issue categories (‘technological change’) copy-pasted from a template; no revision since creation
Role determination	Per AI system: provider / developer / user, with the fine-tuned and embedded cases decided explicitly	One blanket role for the whole organisation — contradicted by the first engineer interviewed
AI policy	Answers what is forbidden, what needs approval, who decides; frames measurable objectives	Interchangeable principles prose — swap the logo and it fits any company
Risk criteria	One scale, defined likelihood/consequence anchors, acceptance thresholds signed by risk owners	Scoring that changes per workshop, so no two assessments are comparable
Risk register + treatment plan	Each treatment traces to a risk; residual risk explicitly accepted by a named owner	Controls with no parent risk; residual risk accepted by silence
Statement of Applicability	Every control’s inclusion or exclusion justified in your own words, traceable to risk decisions; version-controlled	All controls ‘applicable’ with identical justifications — or exclusions that just say ‘not applicable’
AI objectives	Three to seven, measurable, owned, with dates — the targets clause 9 will report against	‘Be a leader in responsible AI’ — unmeasurable, unowned, unfalsifiable

SoA craftsmanship deserves its own paragraph because the Statement of Applicability is the first document your auditor reads and the index they sample everything else through. The chain is fixed — risks → treatments → necessary controls → Annex A completeness check → SoA — and the annex-a-controls module drilled the applicability logic. The implementer’s craft is in the sentences: each justification written in your organisation’s own words, naming the risk or requirement that put the control there; each exclusion phrased to survive a hostile read (‘we perform no model development; see role determination v3’ survives — ‘not applicable’ does not); and a version history proving the document moves when the risk register moves. Budget real hours for this. A day spent on SoA sentences saves a week of Stage 2 argument.

Objectives and change planning close out the plan. Objectives should be few, measurable, and owned — ‘100% of in-scope systems have a current impact assessment by Q2, owner: head of product’ is auditable; aspiration is not. And clause 6.3’s planning-of-changes duty means the AIMS itself changes deliberately: a simple change log — what changed, why, who approved, which artifacts were updated — is the cheapest evidence in the whole system and the first thing surveillance auditors ask for.

The consultant-shaped hole

A document pack bought from a consultancy fails in two stages. First the artifacts flunk every ‘appropriate to the organisation’ test above — generic context, transplanted policy, an SoA justifying controls against risks nobody here assessed. Then, at Stage 2, the deeper failure surfaces: nobody internal can defend the decisions, because nobody internal made them. The auditor asks the risk owner why control A.6.2.4 is applicable, and the answer ‘the consultant included it’ converts a paperwork smell into a competence finding. The working rule: consultants may facilitate and hold the pen — your risk owners must make and be able to explain every decision. This is also the first appearance of a failure pattern lesson 5 names properly: hero-dependency, with the hero not even on payroll.

Tool: AIMS Builder & Audit — Run the planning chain end to end: scope a fictional organisation, determine its AI roles, and craft an SoA whose justifications survive a hostile read.

Key terms: Statement of Applicability, ai policy, risk criteria, ai objectives

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.