AI Audit for Enterprises

An enterprise AI audit programme needs to answer two questions at once: what is known about each material system, and what is known about the shared controls on which several systems depend. Reviewing every application as if it were isolated wastes effort. Treating one platform review as assurance over the whole portfolio creates a different problem: local configuration, workflow and decision risks disappear from view.

The practical goal is a traceable portfolio of conclusions, each tied to a system, claim, version, period and evidence boundary. Senior management should be able to see where work can be reused, where local testing remains necessary and which unresolved issue prevents a particular decision. An average “AI assurance score” cannot substitute for that information.

Define the audit unit below the brand name

A single enterprise AI platform can host many applications with different users, data and permitted actions. Conversely, one business workflow can depend on several suppliers and internal components. The audit unit should be the combination needed to answer the claim: application, workflow, configuration, user population and relevant dependencies. A product licence count is not an adequate audit universe.

Record the business owner, technical owner, intended use, deployment state, data sources, actions, languages and material changes. Distinguish an experiment from a production service, and distinguish a dormant deployment from an actively used one. An inventory entry that says “copilot” without describing what it can see or do does not support meaningful prioritisation.

The IIA's AI Auditing Framework distinguishes governance, management and internal audit roles. It is useful professional context for an enterprise programme, but the portfolio design below is an original operating approach. It does not claim that a completed inventory or a framework mapping proves every system is controlled.

A hypothetical portfolio of seventeen systems

Consider an enterprise with seventeen AI systems: five knowledge assistants, four predictive applications, three tool-using agents, three document-processing applications and two multimodal applications. Twelve use a shared identity service, and nine use a shared model gateway; those sets overlap. Some applications are vendor controlled, while others are internally developed. These numbers are invented to illustrate programme design.

The enterprise wants to approve selected releases and understand material gaps across the portfolio. It cannot answer that question by commissioning seventeen identical chatbot tests. Nor can it audit the model gateway once and mark all nine dependent applications complete. The programme must distinguish common evidence from system-specific claims.

Illustrative audit units across the seventeen-system portfolio

Group and count	Potentially shared evidence	Local question that remains
Five knowledge assistants	Identity lifecycle and gateway configuration	Does each assistant respect its own source permissions and answer criteria?
Four predictive applications	Data platform change controls and common deployment tooling	Are each model's target, evaluation population and decision thresholds appropriate?
Three tool-using agents	Credential management and shared logging components	Are each agent's actions and approval boundaries enforced at the destination?
Three document applications	File handling and storage controls	Are task-specific extraction, redaction or classification outcomes reliable enough?
Two multimodal applications	Common infrastructure and release processes	Do the tested input conditions and output uses match the actual workflow?

The categories organise work; they are not risk ratings. One small agent with consequential authority may deserve attention before several large read-only assistants. One predictive application can require specialised evaluation that does not apply to its neighbours. Use the inventory to locate important questions, then define the procedures for each claim.

Shared control reliance needs an applicability test

Before reusing a shared-control result, confirm that the application actually uses the assessed service, configuration and operating period. Check local overrides, alternate paths, legacy integrations and customer-managed settings. A central identity service can provision users correctly while an application maps their roles incorrectly. A gateway can record model requests while a side integration bypasses it.

Define a reliance packet for the shared control: owner, purpose, tested boundary, versions, period, procedures, exceptions, evidence location and conditions for application reliance. Each application owner then confirms the relevant implementation relationship, supported by evidence rather than a declaration alone. The local audit records what additional checks were needed and what could not be established.

For the hypothetical identity service, suppose ten of the twelve dependent applications have evidenced configuration alignment, while two have unresolved local overrides. The shared result can contribute to the ten claims within its limits. It should not automatically clear the other two. This is an illustration of reliance reasoning, not a rule that ten checks or a particular percentage is sufficient.

Build a coverage ledger, not a green dashboard

A coverage ledger records claims examined, evidence obtained and conclusions reached for each audit unit. Use distinct states for planned, in progress, completed within scope, limited by missing evidence and not examined. Completion describes the work status, not whether the system passed. A completed assessment can contain a material unresolved finding.

Illustrative portfolio status without concealing unresolved issues

Work status	Systems	What management can infer	What it cannot infer
Completed within agreed scope	9	Reports exist for the named claims; one includes a material unresolved finding	All nine systems are approved or free of material risk
Partially examined	5	Some claims have evidence; remaining limitations are visible	Untested claims share the results of completed procedures
Not yet examined	3	The programme has identified outstanding work	Absence of findings means low risk

The counts add to seventeen, but the management decision depends on the claims and consequences behind them. A high completion percentage cannot offset an unresolved action-authority failure in a system proposed for release. Tested and not-tested coverage should be visible at both application and portfolio level so aggregate reporting does not erase the boundaries of individual conclusions.

Prioritise with consequences and dependencies

Assess potential effects on people, operations, finances, confidential information and required obligations. Consider external communication, automated action, reversibility, scale, uncertainty and evidence access. Then consider dependency concentration: a shared service affecting many applications may warrant early attention even when no single use appears dominant.

A ranking should support a decision, not produce mathematical theatre. If the enterprise uses a score, show the factors, assumptions and override reasons. Do not average an important legal or safety question into insignificance because other factors are low. The prioritisation owner should be able to explain why a system is reviewed now, later or under an interim restriction.

Dependencies also affect the order of work. Examining a shared permission service first may clarify several local scopes. But waiting for a broad platform review should not delay a targeted examination of an urgent local risk. The programme needs both planned cycles and a route for material change or incident-driven work.

Separate common methods from identical tests

Use consistent definitions for scope, evidence status, findings and limitations, while allowing procedures to differ by system. A common report structure improves comparability; a common chatbot test set imposed on predictive models does not. Technical specialists should explain why the selected method answers the relevant claim and what uncertainty remains.

For predictive applications, reference outcomes, temporal separation and decision thresholds may dominate. For agents, authority and confirmed effects may matter more. For document processing, field-level errors and downstream handling can be decisive. The enterprise programme should preserve these differences while requiring a consistent evidence-to-conclusion chain.

Standardise the record, not the conclusion. Every finding can identify a criterion, condition, evidence, consequence and owner, but severity needs context. The same technical defect may have different exposure in a draft-only assistant and a system that can execute changes. A shared rating vocabulary should not conceal those differences.

Coordinate central and business-unit evidence

Central teams often own identity, hosting, model gateways and policy. Business units own task definitions, source quality and decisions based on outputs. Vendors may control model internals or operating records. The audit needs a responsibility map that identifies where evidence comes from and who can resolve a gap. “The platform team handles it” is not enough when the claim depends on local configuration.

Set a common evidence request format with a named claim, version, period and purpose. Reuse verified shared material through controlled references instead of making every unit upload another copy. Preserve local evidence where it differs. This reduces burden while avoiding a central repository so broad that access and retention become difficult to govern.

If a business unit disputes a common assumption, investigate the exception rather than forcing conformity in the inventory. A local integration may legitimately differ from the enterprise pattern. The programme should expose that difference and adjust the scope, not treat the standard architecture as proof of the deployed one.

Keep the assurance roles distinct

Management owns AI use and risk decisions. Operational and specialist functions can design controls, monitor performance and provide evidence. Internal audit or another appropriately arranged evaluator examines agreed questions with the relevant independence and competence. The IIA's Three Lines Model provides useful role context; applying it still requires a clear local allocation of responsibilities.

A central AI office should not become the sole source, tester and approver of every claim without challenge. Equally, audit should not take ownership of the controls it later evaluates. When external specialists participate, specify who performs procedures, reviews technical judgement and owns the final report. Independence analysis is particularly important where a supplier also built or operates the application.

Coordinate assurance providers so the enterprise can see duplication and gaps. A security review, privacy assessment, model validation and technical AI audit may each contribute evidence. Their scopes and professional status differ. A consolidated programme report should preserve those boundaries rather than announce that the organisation is “fully assured” because several reviews exist.

Version and change management preserve relevance

Record the baseline for each conclusion: model, application, configuration, data sources and relevant dependencies. Then define change events that require review of continued reliance. A new model may affect performance; a permission change may affect access; a new tool may affect action authority. Not every change requires repeating every procedure, but the decision to reuse evidence needs a reason.

Shared changes can have a wide blast radius. If the model gateway changes its logging format, several applications may lose evidence needed for investigation even if their visible output is unchanged. The programme should identify affected claims and test the relevant paths. A platform release note saying “backward compatible” is a starting point for analysis, not conclusive evidence for every downstream application.

Continuous AI auditing can help define recurring independent review of selected monitoring evidence and changes. It should not be confused with the operating team's own dashboard. The programme needs to show which evidence is reviewed, by whom, at what triggers and with what limitations.

Resource the programme by expertise and bottlenecks

Portfolio planning should identify scarce skills, evidence owners and supplier participation. Seventeen systems do not imply seventeen equal work packages. Some may share evidence; others need specialised testing or restricted-access arrangements. Budget for quality review and the investigation of material exceptions, not only execution of a fixed test count.

Sequence work around dependencies while preserving the ability to respond to urgent issues. A common evidence-readiness process can reduce avoidable delay, but should not become a reason to postpone every system until the whole enterprise is perfectly documented. Scope a useful decision with the evidence available and make the resulting limitations explicit.

Measure programme progress by resolved claims, coverage quality and verified remediation. Hours spent and systems counted are useful management inputs, but can encourage shallow completion if treated as the main success measures. A difficult finding kept open for valid reasons may be more informative than an easily closed low-consequence action.

Propagate a shared finding without losing local meaning

When a common control fails, identify which applications actually depend on the affected behaviour. Do not copy the same finding into every system and assume that duplication improves coverage. Equally, do not leave it only in a central report where business owners never see the consequence. Maintain one underlying issue with linked application effects, local restrictions and verification requirements.

In the hypothetical portfolio, a shared identity defect may affect twelve registered dependants, but a local configuration could reduce or increase exposure. The central team owns the common repair; each relevant application still needs evidence that the repaired control is used correctly. Closing the central engineering ticket does not automatically close all local reliance questions. The programme should distinguish common implementation from application-level verification.

Count findings and affected systems separately. One common defect with several effects is not necessarily several independent defects, while one application can have multiple unrelated findings. Executive reporting should explain both dimensions. Otherwise the same repair can appear to close a large number of issues without showing whether the underlying consequence was verified in each material use.

Handle different entities, periods and suppliers explicitly

An enterprise programme may span legal entities and operating contexts with different requirements and decision authorities. A group policy can provide a common baseline without proving that every local obligation has been assessed. Record who determines applicability for each relevant use and how that determination enters the criteria. Do not treat central approval as a substitute for a local requirement that has not been examined.

Evidence periods can also differ. A shared-service report may cover one period, while a local application audit covers a later release. Identify the overlap and changes between them. A statement that nothing material changed may be useful evidence to examine, but should not automatically bridge every gap. The reviewer needs a reasoned account of continued relevance, especially where operating effectiveness is the claim.

Supplier changes require the same discipline. If an application moves to another model service while retaining its interface, the dependency map and evidence basis may change. If an acquisition introduces a new tenant or configuration, it should not inherit the parent company's conclusions by association. The programme can reuse genuinely common work while keeping the new or changed boundary visible.

Assign an owner to maintain these relationships. A dependency map that is accurate only during the audit workshop will quickly lose value. Connect updates to release, supplier and inventory processes already used by the organisation. The audit can then examine whether material changes reach the programme rather than depending on informal recollection at the next annual planning meeting.

This approach also makes assurance spending easier to explain. Central work is valuable when its result can be used under clear conditions; local work is valuable when it resolves questions the shared evidence cannot. The programme should be able to show that distinction without claiming that every reused document saves a fixed amount or that a larger audit count necessarily means better control.

What the executive and board report should preserve

Show the decisions required, material unresolved findings, important limitations and concentration in shared dependencies. Explain which releases or uses are restricted and who owns the next action. Keep system-level detail available for challenge, but do not force directors to interpret raw evaluation metrics without business context.

State the portfolio denominator and its uncertainty. If informal uses or recently acquired systems are still being discovered, seventeen may be a current registered population rather than a complete universe. Report that distinction. A percentage of registered systems reviewed should not be presented as a percentage of all enterprise AI risk controlled.

The board AI audit guide explains how to connect evidence to governance decisions. The underlying working papers should make material conclusions traceable, including where the programme relies on another review. An enterprise conclusion is credible when its reader can find the exceptions and limits, not only the completed work.

For an audit scoping discussion for an enterprise AI portfolio, bring the inventory, shared-service map, planned releases and material uncertainties. Open for AI's AI auditing services can be scoped to specific systems and shared claims within that programme. The result should help the enterprise reuse sound evidence while retaining the local tests its decisions still require.