The NIST AI Risk Management Framework (AI RMF 1.0) was published in January 2023. In the three years since, it has quietly become the de facto audit standard for enterprise AI governance in the United States — and, through mutual recognition agreements and global enterprise procurement requirements, a material compliance concern for any organisation supplying AI-enabled services to US federal agencies, large US corporates, or financial institutions with US parent companies.
For South African organisations, the AI RMF matters on two levels. First, it is a template. The NIST framework is rigorous, practically structured, and maps clearly to the principles embedded in POPIA and the nascent South African AI governance guidance emerging from DCDT and the Information Regulator. Second, it is often a commercial requirement. If you want to sell AI-enabled services to a US bank, a US healthcare organisation, or a US government contractor, you will be asked about your AI RMF alignment.
What NIST AI RMF Actually Is
The AI RMF is a voluntary framework — NIST does not certify compliance and there is no formal audit scheme. What exists instead is a structured vocabulary and a set of outcomes that organisations are expected to demonstrate. The framework is organised around four functions: GOVERN, MAP, MEASURE, and MANAGE. Each function contains categories, and each category contains subcategories — specific outcomes that describe what good looks like.
The practical effect is that when a sophisticated buyer, auditor, or regulator asks about your AI governance, they will use this vocabulary. If you cannot map your practices to GOVERN, MAP, MEASURE, and MANAGE, the conversation becomes difficult quickly. If you can, you have a structured way to demonstrate maturity without having to build your own framework from scratch.
GOVERN: Establishing Accountability
GOVERN is about organisational accountability for AI risk. It asks: who in the organisation is responsible for AI risk? What policies exist to guide AI development and deployment? How are AI-related risks escalated and reported? Is there a documented risk tolerance for AI systems?
Evidence auditors want for GOVERN: An AI governance policy document with named owner and approval date. A documented risk tolerance statement for AI systems (e.g., 'AI agents with blast radius scores above 70 require CISO sign-off before production deployment'). A defined escalation path for AI-related security incidents. Board or executive committee awareness of material AI risks.
The most common gap at the GOVERN level is the absence of documented AI-specific risk tolerance. Most organisations have general IT risk policies that reference risk appetite. AI agents require a more granular treatment — the risk profile of an AI agent with read-only S3 access is fundamentally different from one with iam:PassRole and outbound internet access, and the governance documentation needs to reflect that distinction.
MAP: Building the Inventory
MAP is about understanding the AI systems you have deployed and the context in which they operate. It asks: what AI systems are in use across the organisation? What are their intended purposes? Who are the users, and what are the impacts if the system fails or is compromised? What external dependencies does each system have?
Evidence auditors want for MAP: A maintained inventory of all AI systems, including agent name, owner, deployment environment, data sources, external API dependencies, and IAM role ARN. Impact assessments for each system documenting: who is affected if this system fails, what data could be exposed if it is compromised, and what financial or operational impact results from a 4-hour outage.
MAP is where most organisations start and where most immediately struggle. Building the inventory requires discovery — finding the agents that exist, not just the ones that were formally approved. An inventory that covers only formally approved agents is both incomplete and misleading. Auditors who understand AI infrastructure will ask about discovery methodology. 'We asked our teams' is not a methodology.
MEASURE: Quantifying Risk
MEASURE is about evaluating the risk of each AI system in a structured and repeatable way. It asks: what is the risk level of this system? How was that risk level determined? Are the measurements consistent and comparable across systems? How are new risks detected and incorporated into the measurement?
Evidence auditors want for MEASURE: A documented risk scoring methodology for AI systems (this is what blast radius scoring provides). Risk scores for every system in the MAP inventory, with scoring dates and the inputs used. Evidence that high-risk systems have been reviewed more recently than low-risk systems. A process for re-scoring systems when their permissions, data access, or deployment context changes.
The MEASURE function is where frameworks like Amajoni's blast radius scoring connect directly to the AI RMF. A repeatable, documented scoring methodology that produces consistent output across your AI agent inventory is exactly what MEASURE requires. CVSS was not designed for this class of system — it does not account for prompt injection, tool chaining, or the semantic attack surface of an LLM agent. AI-specific scoring is not optional; it is what MEASURE is asking for.
MANAGE: Controlling and Remediating
MANAGE is about acting on the risk information produced by MAP and MEASURE. It asks: what controls are in place to reduce the risk of high-risk systems? How are incidents responded to? How are remediations tracked and verified? What residual risk has been accepted and by whom?
Evidence auditors want for MANAGE: A remediation register with open and closed findings for AI systems, including who owns each finding and its target resolution date. Incident response procedures specific to AI systems (prompt injection, data exfiltration, rogue agent behaviour). Evidence of control implementation — IAM policies, CloudWatch alerts, access reviews. Documented risk acceptance decisions for findings not immediately remediated, signed by the appropriate authority.
Common Implementation Mistakes
- Treating the AI RMF as a documentation exercise. The framework describes outcomes, not documents. A GOVERN policy document that nobody enforces, a MAP inventory that is six months out of date, and a MEASURE score that was calculated once and never updated are evidence of a compliance theatre exercise, not a functioning programme. Auditors can tell the difference.
- Building the inventory from approvals rather than discovery. Formally approved AI systems are a subset of deployed AI systems. The gap between the two is exactly what attackers exploit. MAP requires discovering what actually exists, not documenting what should exist.
- Applying CVSS to AI systems. CVSS was designed for traditional software vulnerabilities. It does not model the unique risk dimensions of AI agents: the natural language attack surface, the tool chaining risk, the context window sensitivity, the drift between intended and actual behaviour. A CVSS score for an AI agent is not wrong — it is the wrong question.
- Ignoring third-party AI components. Every LLM API you call, every AI tool you use, every third-party agent framework you integrate is a dependency in your AI RMF scope. If a major LLM provider is compromised or changes their model behaviour, your risk profile changes. Mapping these dependencies is part of MAP and monitoring them is part of MANAGE.
- Scoping the AI RMF to customer-facing systems only. Internal AI tools — HR agents, finance automation, code review agents — often have access to highly sensitive data and receive less security scrutiny than customer-facing systems. The blast radius of an internal agent with access to payroll data or source code can be as high or higher than a customer-facing agent.
Mapping Your AI Agent Inventory to Each Function
For each AI agent in your inventory, you need to produce four artefacts that map to the four functions. This is the minimum viable AI RMF implementation.
- GOVERN artefact: An owner record — name, team, contact, and a documented acknowledgement that this person is responsible for the risk associated with this agent.
- MAP artefact: A system profile — purpose, data sources, tool access, IAM role ARN, deployment environment, user population, and a brief impact statement covering confidentiality, integrity, and availability failure modes.
- MEASURE artefact: A risk score — calculated using a documented, repeatable methodology — with the date of calculation and the inputs used. Scores should be recalculated whenever permissions, data access, or deployment context changes significantly.
- MANAGE artefact: An open findings register for this agent — remediations in progress, controls implemented, risk accepted by whom, and next review date.
The EU AI Act Overlap and What It Means for SA Companies
The EU AI Act, which entered force in 2024 and has been applying in stages since, creates a tiered risk classification for AI systems. High-risk AI systems — those used in credit scoring, employment decisions, biometric identification, critical infrastructure, or law enforcement — are subject to mandatory conformity assessments, technical documentation requirements, and human oversight obligations.
South African companies with EU operations, EU customers, or EU-domiciled partners are in scope for the AI Act where their AI systems affect EU residents. For a South African fintech processing EU card transactions, a South African logistics company serving EU clients, or a South African BPO handling EU customer data, this is not a theoretical concern. The AI Act's documentation requirements overlap substantially with NIST AI RMF outcomes — particularly in MAP (system documentation) and MEASURE (risk assessment). Building AI RMF capability effectively builds EU AI Act readiness.
90-Day Implementation Checklist
- Days 1–14: Discovery. Run passive scans across your cloud environments to identify Lambda functions, ECS tasks, and EC2 instances with LLM API keys or AI framework dependencies. Use the three signals from our previous article. Do not rely on self-reporting from engineering teams.
- Days 15–30: Inventory build. For each discovered agent, complete the MAP artefact: purpose, data sources, IAM role, deployment environment, impact statement. Assign an owner to each agent. If no owner can be identified, escalate to engineering leadership.
- Days 31–45: Risk scoring. Apply a documented scoring methodology to every agent in the inventory. Prioritise agents in production environments with access to customer data or with dangerous permissions. Document the score, date, and inputs for each agent.
- Days 46–60: High-risk remediation. For agents scoring above your defined threshold, open a finding and begin remediation. The most impactful single action is permission reduction — apply least-privilege IAM policies with resource-level ARN restrictions.
- Days 61–75: Detection deployment. Deploy CloudWatch Logs Insights queries as saved queries with alerts for the most dangerous anomaly patterns: external SES sends from agent roles, bulk data reads, and IAM activity from agent roles.
- Days 76–90: Governance documentation. Produce the GOVERN artefacts: an AI governance policy with documented risk tolerance, an escalation path for AI incidents, and a board-level risk summary covering your highest-scored agents. Schedule quarterly inventory reviews.
The organisations that will find AI RMF implementation easiest are those that start with discovery — knowing what they have — rather than with documentation of what they approved. Approval processes do not surface shadow agents. Discovery does.