CSA AICM AI Risk Assessment: Turn Model Use into Owned Decisions

An AI risk assessment becomes useful when it names a deployed function, a data flow, a model route and the person accepting the remaining exposure. "Generative AI may disclose sensitive data" belongs in a workshop. "The support summarizer can send account notes to endpoint X under a shared service credential" belongs in a risk register because engineering can test it and a named owner can treat it.

CSA AI Controls Matrix version 1.1 supplies the control structure for making that transition.

TL;DR

• AICM GRC-02 requires a documented, leadership-sponsored AI risk management program covering identification, evaluation, ownership, treatment and acceptance.
• Scope the deployed use case and your role, then map identities, data, model routes, providers, outputs and business actions.
• Test controls against concrete threat scenarios and preserve the result, evidence, treatment, owner, due date and residual-risk decision.
• DeepInspect covers authenticated HTTP user or agent traffic routed to LLMs. Endpoint, cloud, training, model-weight and business-process risks require separate controls.

GRC-02 defines the management spine

The CSA AI Controls Matrix version 1.1, released June 22, 2026, contains 247 control objectives analyzed across ownership, architecture, lifecycle and threat dimensions. GRC-02 requires a formal, documented, leadership-sponsored AI Risk Management program with policies and procedures for risk identification, evaluation, ownership, treatment and acceptance.

Every word in that sequence carries an artifact. Identification produces a scenario tied to an asset or process. Evaluation records likelihood, impact and the basis for both. Ownership names the person with authority to fund or accept treatment. Treatment points to a control change and due date. Acceptance records the residual exposure and approval.

That structure differentiates this article from the AICM compliance checklist. A checklist asks whether a control activity exists. The risk assessment explains which scenario drove the activity, how well the control performed and who owns what remains. The AICM controls mapping then helps place each treatment against the relevant domain.

Scope starts with a use case and actor role

AICM assigns responsibilities according to the service actor's place in the AI stack. The roles cover model development, orchestration, application delivery, customer use and cloud infrastructure. Start by recording which role the assessed entity occupies for this use case. An enterprise can occupy more than one role across different products, so the answer belongs at the assessment level rather than in a permanent company label.

Name the production function in operational terms. Include its users and business purpose, the application owner, the model and endpoint, the orchestration layer, connected data sources, tools the model can call and actions the application can take. Record the regions and customer groups involved. Add current model and policy versions.

Then draw the request path. A clean diagram can fit on one page: authenticated user or agent, application, policy point, orchestration component, model endpoint, response path and any action execution. Mark each trust boundary and evidence source. The exercise exposes shared credentials, direct provider routes and side paths absent from the approved architecture.

A spreadsheet with 60 generic AI risks creates motion. One diagram with three real routes creates decisions.

Threat scenarios need a cause and consequence

The AICM organizes controls against threat categories, while TVM-04 requires threat analysis and modelling for cloud and AI systems. Write each scenario as an observable chain. Name the initiating condition, the route through the system, the affected asset or person and the business consequence.

For the authenticated HTTP request boundary, useful scenarios include:

• A user with legitimate application access sends restricted customer data to an approved model for an unapproved purpose.
• An agent operating under a broad service identity reaches a model or route outside its delegated task.
• Retrieved content carries a prompt-injection string that changes the request and elicits restricted output.
• Sensitive material in a model response reaches the caller because response policy covered only the prompt.
• New endpoints enter production without inventory, contract review, data-region approval or logging coverage.

Other AICM scenarios sit elsewhere. Model artifact tampering, poisoning during training, compromised developer endpoints, cloud control-plane failures and local tool execution need owners and controls at those layers. Include them in the larger assessment when relevant, while keeping the enforcement claim attached to the mechanism that can actually act.

Evaluation should expose assumptions

A risk score often compresses several judgments into one coloured cell. Preserve the supporting judgments underneath that final score. Record the population exposed, data sensitivity, action authority, route reachability, detectability and recovery path. Note the source of each assumption and the date it was checked.

The AICM version 1.1 implementation guidelines for application providers connect risk work to several controls. A&A-03 calls for risk-based assessment planning and reassessment after significant changes or emerging risks. BCR-02 covers the impact of operational disruptions. MDS-11 requires a risk-based evaluation of model and serving failures. MDS-12 addresses risk assessment for open models. STA-10 requires periodic review of supply-chain relationships. TVM-04 provides threat-model input for the mitigation strategy.

For an HTTP disclosure scenario, test the path rather than rating the policy document. Use an account with a known role. Send a controlled payload carrying the classification that should trigger the rule. Record the destination selected, policy version, decision, response handling and generated evidence. Repeat with an allowed case so the team can see both sides of the boundary.

On a review call, the useful detail is the red test payload blocked at 14:06 under policy revision 37. "DLP control implemented" offers much less assurance.

Control effectiveness belongs beside inherent risk

Inherent risk describes the scenario before the assessed controls. Control effectiveness records what the deployed mechanisms did under test. Residual risk reflects the exposure after those controls and any known gaps. Keep all three elements visible in the assessment record.

For request-boundary scenarios, assess identity binding first. A model API key identifies the calling application, while the control decision may need the human or agent represented by that call. Verify that the application supplies authenticated identity and role context and that the policy record retains it.

Next, test content classification on the assembled prompt. Document labels inherited from source systems, then test the context window as transmitted. A prompt can combine fragments that produce a higher sensitivity than any individual source. Our prompt-level DLP guide explains that inspection point.

Then test destination authorization, response policy, failure behavior and evidence independence. Ambiguous policy or unavailable enforcement should follow the approved failure rule. Logs should reach a secured store with correlation fields before an incident requires them. Each test produces evidence for the assessment and a baseline for later change review.

Treatment plans need engineering verbs

"Improve governance" cannot close a risk. A treatment plan should say which team changes which mechanism by which date, then name the retest that proves completion.

Useful treatments include replacing a shared application identity with user or agent context supplied on each request, restricting a role to an approved endpoint set, adding prompt and response classification, denying direct provider routes, versioning policy, centralizing decision records or adding a fallback for model failure. Supply-chain treatments may add contract rights, provider evidence, inventory reconciliation or a replacement route. Model treatments may require updated evaluation, provider remediation or withdrawal of a version.

Link every treatment to the AICM control it changes and preserve the implementation ticket, approval, deployment record and test result. The AICM audit-evidence guide covers how those artifacts read during assessment.

My opinion is simple: a residual-risk acceptance signed by someone without budget or operational authority is administrative theatre. The owner must be able to fund the fix, change the service or stop the use case.

Change triggers keep the assessment alive

An annual review can satisfy several AICM cadence statements, but AI services change faster than that schedule. A&A-03 explicitly adds significant changes and emerging risks. Build event-driven triggers into the record.

Run a targeted reassessment when the model or provider changes, a new data source joins retrieval, an agent gains another tool, a role receives broader access, a route enters a new region or the application starts storing prompts or responses differently. Trigger one after a material incident, a provider assurance change, a new regulatory obligation or a threat technique that defeats an assumption in the current model.

The change record should identify which scenarios and controls were reconsidered. A model-version update may affect output behavior and monitoring without changing identity policy. A new provider can change destination, contract, data region, retention and supply-chain risk at once. Scope the reassessment to the facts, then record why unaffected areas stayed unchanged.

The official STAR for AI programme uses the AI-CAIQ self-assessment for Level 1. A maintained risk register supports those answers by connecting policy claims to current tests, owners and accepted residual exposure.

Shared responsibility sets the assessment boundary

Application providers own controls in their application infrastructure and the services they deliver. Model providers own model-development and service controls. Orchestrated service providers own their integration layer. Cloud providers control the relevant underlying infrastructure services. AI customers own internal use and business-process decisions. Contracts and assurance reports transfer evidence between those parties, while accountability remains allocated by the real architecture.

For DeepInspect, the assessable boundary is authenticated HTTP traffic that users or agents deliberately route through the proxy to LLM endpoints. Within that path, tests can cover application-supplied identity and role, prompt and response classification, destination authorization, policy decision and independent evidence.

Direct calls around the configured route, stolen credentials, compromised endpoints, local execution, STDIO traffic, provider training pipelines, model weights and physical infrastructure sit outside that boundary. A complete AICM risk program still assesses them under their proper owners. Stating the limit gives the risk committee a truthful control map and prevents one product entry from absorbing risks it cannot affect.

DeepInspect

DeepInspect provides a policy decision point on the authenticated HTTP path between users or agents and LLM APIs. For traffic deliberately routed through it, policies can evaluate application-supplied identity and role, content classification and model destination before the request reaches the endpoint. Response policy can evaluate traffic returning through the same path.

Each decision creates a signed, tamper-evident record outside the calling application's write path. That gives an AICM assessment a repeatable control test and evidence for the request-boundary scenarios. Model training, endpoint security, cloud infrastructure, local tool execution, business impact analysis and residual-risk approval remain with the systems and people that own them.

Book a technical deep dive at deepinspect.ai.