Is this checklist enough for a COBIT assessment?

It covers the AI-traffic obligations a COBIT walkthrough reaches for: identity, classification, policy enforcement, risk measurement, change control, decision lineage, exception reporting, evidence independence, and retention. A full assessment also grades organizational structures, skills and competencies, culture, and the service and infrastructure components of the governance system. Treat this as the AI-specific layer inside a wider COBIT programme.

What capability level does this get an AI process to?

Level 3, the established process level, is a reasonable target once each item produces its documented work product on every run. Reaching level 4 adds quantitative management, which means the measurements in item 4 have defined targets and the process is controlled against them. Level 5 adds continuous improvement driven by those measurements.

Which items matter most if we only do three?

Identity binding, prompt classification, and evidence write-path independence. The first two make every downstream record meaningful, and the third decides whether an auditor treats the records as evidence or as an assertion by the party under review.

Does COBIT accept vendor logs as evidence?

Model provider logs describe the provider's view of API consumption without your identity context or your policy decisions, and they sit outside your custody. That combination fails MEA04 independence and DSS06 traceability at once, so the record has to be produced on your side of the request boundary.

How does this sit alongside ISO 42001 or SOC 2?

The artifacts overlap almost completely. An identity-bound, classified, independently written per-request record answers COBIT DSS06, ISO 42001 audit evidence expectations, and the SOC 2 common criteria for AI. Building it once and mapping it three ways is the pattern that survives multiple assessment cycles.

COBIT AI Compliance Checklist: Ten Items That Move an AI Process Past Capability Level 1

COBIT 2019 grades every governance and management objective on a capability scale from 0 to 5, and level 3 requires a defined process that produces documented work products on every run. An AI usage policy approved by a governance committee scores level 1 against EDM01, because the process exists and produces nothing an auditor can test.

This checklist follows the order an internal audit walkthrough tends to take: identity and classification records first, then risk measurement, then change and configuration, then monitoring and assurance independence. Each item pairs the action with the evidence artifact it produces, because ISACA's 2025 white paper on COBIT and AI system governance applies the existing 40 objectives without relaxing what any of them expects to see.

1. Bind a named identity to every AI request

Route AI traffic so a named user or agent, rather than a shared service key, is attached to each prompt. Evidence is a per-request record showing which identity sent which prompt to which model, and it is the artifact DSS06 traceability rests on once an auditor asks who caused a specific AI-shaped decision.

2. Classify the context window before it leaves

Evaluate the classification of prompt content at the boundary rather than inheriting a document label from a source system, since a prompt assembles fragments that no catalogue classified as a unit. Evidence is a per-request classification decision, which is what APO14 data management asks for when the data in question exists for the duration of one API call.

3. Enforce per-role, per-route policy in the request path

Replace permanent full-model access granted by a shared API key with policy attached to roles and routes, failing closed on ambiguity. Evidence is the enforcement log showing which roles reached which models, satisfying the APO13 security management practice at the point where AI traffic differs from ordinary traffic.

4. Measure residual AI risk from traffic, not from a workshop

Derive the APO12 risk profile from counts of permitted and blocked requests by classification, role, and destination over the assessment period. Evidence is a measured residual position, and it replaces the consensus rating that an auditor will ask you to substantiate the moment they see it.

5. Record the destination endpoint and its region

Log the model endpoint and jurisdiction for every request carrying regulated data, because a prompt sent to an endpoint in Oregon or Dublin is a transfer whatever the contract says. Evidence is a destination log, which AI data residency controls produce at the moment of transmission rather than at procurement.

6. Version the policy and stamp it on every decision

Treat a model swap, a system prompt edit, or a route change as a managed change under BAI06 and a configuration item under BAI10, then stamp the active version onto each decision record. Evidence is a configuration history joinable to traffic, so a reviewer can reconstruct which model and policy handled a request three months ago.

7. Produce a per-decision record for outcomes that affect people

For any AI output feeding a decision with legal or similarly significant effect, write a record binding the input prompt to the output and the applied policy. Evidence is decision lineage, the same artifact GDPR Article 22 automated decisions requires and the operational half of what MEA03 external compliance reaches for.

8. Report exceptions rather than storing them

Send policy violations, blocked transmissions, and anomalous access patterns into the same exception process that handles other control failures, on a defined cadence. Evidence is a monitoring and deficiency report, which is what separates an MEA02 process at level 3 from a log directory nobody queries.

9. Keep the evidence write path outside the application

Ensure the compliance record is written by a system the application making the AI call has no custody over, so it survives selective logging, later modification, and crash-loss between the model response and the log commit. Evidence is an externally written, signed log, which is the MEA04 independence requirement and the argument I made in You Own the AI Liability, Not the Vendor.

10. Set a retention period and prove you can query it

Fix a retention period for AI decision records that matches your longest external obligation, then run a real query against the oldest data you hold. My honest take: the retention decision is the one item on this list that gets deferred to a follow-up ticket and then discovered during the audit, usually at the point where somebody realizes the logs rolled at 30 days. AI audit log retention requirements covers what the various regimes expect.

How the checklist maps to the objectives

Items 1 through 10 resolve to a handful of enforcement points at the request boundary, laid out in the COBIT AI controls mapping. The audit-evidence view covers what each artifact looks like when internal audit asks for it during a walkthrough. Together they turn this list into a graded process rather than a set of intentions.

DeepInspect

Nine of these ten items produce evidence at one place: the boundary between your users or agents and the LLM APIs they call. DeepInspect sits inline at that boundary. It binds identity to each request, classifies the prompt, enforces per-role and per-route policy, records destination and policy version, and writes a signed per-decision record before the response returns. The checklist becomes a query rather than a scramble.

For an internal audit function grading an AI programme, items 1 and 9 are the two a walkthrough reaches first, because traceability and evidence independence decide how every other artifact gets read. Book a technical deep dive at deepinspect.ai.