AAISM: Governance and Risk Decisions in Practice

AI governance becomes difficult when organizations cannot explain who authorized an AI capability, which data it uses, and what evidence would justify stopping it. A policy that states 'humans remain accountable' offers little protection if nobody is assigned to review decisions or if an agent can change records before a person sees the result. ISACA's AAISM credential places governance and risk management alongside AI technologies and controls because the decisions are inseparable. The AAISM certification is relevant to experienced security professionals translating enterprise risk appetite into workable requirements for AI adoption.

Consider a logistics company using AI to forecast delivery disruptions, draft customer notices, and suggest changes to routing plans. The forecast system observes operational data, the message assistant handles customer information, and the routing agent can influence expensive real-world actions. Even if one provider supplies all three models, their business risks are different. Governance must define which capabilities are informational, which are advisory, and which require formal authorization. Risk management then tests what could go wrong when data is stale, a model makes a mistake, a tool is manipulated, or a vendor changes behavior unexpectedly.

Define governance in terms of actual decisions

The first task is to identify the authority structure around each AI service. A product owner may define the business goal, a data steward approve access to operational records, a security lead evaluate abuse paths, and an executive sponsor accept significant residual risk. Those roles need clear handoffs. If a routing assistant begins making autonomous dispatch changes, the capability has crossed a governance boundary even though its product name has not changed. A new approval may be needed because the potential consequences and accountable operators have changed.

Governance should be proportionate. A team experimenting with synthetic data can follow a streamlined path, while a production system that uses customer information and changes dispatch priorities needs stronger evidence. Standard designs can accelerate safer adoption: approved model access, permission-aware retrieval, protected tool gateways, versioned evaluation, and operational logging. Exceptions should be visible and time-bound. A governance board should not become the operational owner of every system, but it must establish the standards and escalation route that allow actual owners to make informed decisions.

Inventory capabilities and information flows

An inventory of AI products is insufficient if it omits what the products can do. Record business owner, intended users, model and vendor, connected tools, data categories, retrieval sources, deployment environment, decisions influenced, and consequences of failure. Include the path taken by prompts, responses, and diagnostic logs. Sensitive information can flow into third-party analytics or support tools even when the main model provider has appropriate controls. Data mapping is necessary for privacy, retention, localization, access governance, and incident response.

The logistics company may find that its customer-notice assistant retrieves customer phone numbers only to compose an email draft. That information might not need to reach the model at all if contact delivery is handled by a trusted application service. Minimizing data reduces both privacy exposure and the amount of information an attacker can manipulate. Similarly, a routing model may need aggregate traffic observations without receiving employee disciplinary details. Data minimization is an architectural optimization as well as a governance principle: every unnecessary attribute broadens the possible harm and the obligations of the operating team.

Turn risk appetite into specific thresholds

General statements such as 'moderate AI risk is acceptable' are hard to apply without scenarios. A better approach identifies unwanted outcomes and measurable controls. For the routing system, one risk might be a model recommending a road closure that is already outdated. Another might be an autonomous change affecting hazardous-material transport without review. The first may be addressed through source freshness, confidence checks, and human confirmation; the second may require an explicit prohibition on automated execution. Thresholds should describe acceptable error rates, escalation conditions, and classes of decisions the system cannot make.

A risk assessment should record likelihood estimates with their assumptions and avoid false precision where evidence is limited. Actual impact depends on the workflow, not just the model. A wrong weather summary in an internal dashboard has different consequences from an incorrect instruction sent to a driver. Risk treatment can include redesigning the use case, restricting action authority, requiring two-person approval, improving data validation, or retiring a feature. The owner accepting a residual risk should understand what controls are in place and what new evidence would require re-review.

Examine AI-specific attack and failure scenarios

Prompt injection is an important example because it exploits the similarity between language as instruction and language as data. A malicious delivery-note document could tell an assistant to ignore operational policy or send information to an attacker-controlled endpoint. Model hallucination is a different problem: the system may invent a plausible but unsupported cause of a disruption without an adversary being present. Data poisoning can alter inputs or training material before inference. Tool misuse can occur if an authorized user persuades an agent to exercise overly broad permissions. A useful threat assessment distinguishes these cases rather than applying one generic content filter to all of them.

Assess the path from attacker or error source to consequence. If an agent reads untrusted shipping documents, treat their contents as data and prevent them from changing execution policy. If the agent can modify routes, enforce authorization and policy checks in a deterministic service. If a model may produce an unsupported answer, require retrieval provenance and a refusal or escalation behavior when evidence is insufficient. Attack simulation should verify both model behavior and downstream controls. A rejected unauthorized tool call is useful containment evidence even if the model initially proposed the wrong action.

Manage the model and vendor lifecycle

AI services can change because a model version updates, a retrieval index is rebuilt, a tool schema changes, or the provider adjusts features. These changes may affect quality, latency, cost, or security assumptions. Governance needs a release policy specifying which modifications require evaluation and approval. Keep versioned configuration records and representative test cases so outcomes can be compared. The same control environment may need different testing when the application shifts from summarizing information to using tools. Model performance should be evaluated in the context of the full workflow.

Vendor oversight should address data terms, subprocessors, security events, availability commitments, information deletion, and concentration risk. Two independently branded applications may depend on the same foundational provider or cloud region. The enterprise remains responsible for its chosen integration and business use even when a vendor operates the model infrastructure. A supplier's general security report will not establish whether the company's particular retrieval filter prevents unauthorized document exposure. Due diligence must combine contractual assurances with application-specific validation and operational monitoring.

Evaluate governance with realistic evidence

An effective control framework produces evidence that can be reviewed. For a customer-notice assistant, evaluations may test whether the right customer record is selected, whether draft messages distinguish verified facts from forecasts, and whether unauthorized personal information is excluded. For the routing agent, testing should confirm that prohibited actions cannot execute, that rollback is possible where appropriate, and that intervention points are meaningful. Test cases should include normal activity, edge conditions, stale data, adversarial inputs, and unavailable dependencies. Passing a generic benchmark says little about these business-specific expectations.

Monitoring should identify what has changed and who will respond. Increasing refusal rates might indicate a data availability problem, overly restrictive policy, or adversarial use. A spike in tool failures could be an authentication problem rather than a model defect. Cost anomalies may indicate loops or abuse. The team should maintain traceability while restricting sensitive logs. Evidence should lead to decisions: continue, tune, restrict, suspend, or investigate. Without explicit triggers and decision rights, governance becomes a repository of dashboards whose signals do not alter operations.

Incident response and continuity are governance tests

An AI incident plan must allow selective containment. The logistics company may need to disable automated route changes while retaining read-only forecasts, or substitute manual customer communication when an information source becomes unreliable. Security teams should know how to revoke tool credentials, isolate compromised integrations, preserve evidence, and identify affected users. Business continuity plans must acknowledge that a model can fail through bad output while remaining technically available. Restoring the API connection alone would not restore trustworthy service.

After an incident, the enterprise should analyze not just the immediate failure but the control and approval decisions that made it possible. Did the original risk review consider that tool capability? Was the data source supposed to be authoritative? Were evaluators testing the relevant scenario? Was a reviewer presented with enough information to intervene? These questions connect governance to continuous improvement. Management should revisit policy or design when incident evidence invalidates earlier assumptions, rather than treating every event as a one-time operator error.

Prepare a defensible security-management recommendation

A useful AAISM exercise presents a new AI use case and asks for an approval recommendation with conditions. Identify the business purpose, classify data, map integration boundaries, describe specific harms, propose controls, name operating owners, define acceptance tests, and set a review date. Then change one assumption, such as allowing autonomous tool use or adding a new vendor, and explain how the recommendation changes. This demonstrates judgment that a static checklist cannot capture.

AAISM builds on security management practice represented in other ISACA certifications, while requiring applied knowledge of AI governance, threat mechanisms, and technical controls. The durable lesson is that the organization must be able to explain not only how an AI system was built, but why it was permitted to operate, how its risks are bounded, and what evidence would justify intervening. That is what turns AI policy from a statement of intent into an operational security program.