AI Governance Framework: Owners, Controls and Review Evidence

A useful framework connects organisation-wide rules with decisions about individual uses. The rules establish responsibilities and permitted behaviour; each use-case review records how those requirements apply to a particular workflow. Our AI governance page explains the broader register and delivery approach. Here, the focus is the evidence a reviewer needs before approving or changing a use.

The amount of review should reflect the consequences of failure. An internal drafting aid and a system authorised to change customer records need different checks. A practical starting point is to identify who could be affected, which information is involved and how an incorrect result could be corrected.

Current Australian guidance separates organisation-wide arrangements from system-specific work. The National AI Centre’s implementation guidance covers accountability, testing, monitoring and human oversight. It also distinguishes risks arising from different uses of the same tool. It provides a reference for assessment, rather than evidence that a particular implementation is ready.

The approval record should name the person responsible for the business use. That person needs enough information to decide whether the proposed conditions are acceptable, and a clear route for resolving questions they cannot assess themselves. Listing a department without identifying who can make the decision leaves the approval difficult to follow up.

Technical operation and business approval can belong to different people. A delivery team may configure access and investigate failures, while a process owner decides whether the output is suitable for the work. The record should distinguish those responsibilities, including who can suspend use and who must agree before it restarts.

Supplier involvement adds responsibilities that need to be agreed explicitly. Hosting, model provision, integration and day-to-day operation may sit with different parties. For each dependency, the review should establish how changes and problems reach the people responsible for the business workflow.

The review record should let another person reconstruct the decision. A list of controls provides little explanation unless it identifies what each control addresses, how it was checked and which limitations remain. The following is an editorial starting template to adapt to the use case, rather than a certification checklist.

Evidence should describe the conditions under which a check passed. A test using one set of permissions does not establish the behaviour for another team with different access. Recording the users, data scope and system version makes it possible to judge whether a later change falls outside the original assessment.

Unresolved questions need an explicit disposition. Some may prevent approval; others may be investigated within a restricted trial. The reviewer should record the permitted scope and the evidence required before expanding it, so a limited decision cannot be mistaken for unrestricted approval.

Shadow AI includes uses that sit outside the organisation’s approval or recording process. Staff conversations, a software inventory and authorised usage records can contribute different evidence about those uses. Each method also has limits, which should remain visible in the findings. Our shadow AI page explains discovery and its boundaries.

An inventory entry establishes what has been found, not whether it is suitable to continue. The next step is to identify the task, owner, data and account arrangements, then decide what needs assessment. Unknown information should remain labelled as unknown until someone can substantiate it.

Embedded AI features belong in that assessment too. The National AI Centre’s AI systems register guidance explicitly includes AI within common software packages and distinguishes the register from deeper risk assessment. Recording only separately purchased AI products can leave these features outside the review.

Our published document-assistant experience describes planning work for an Australian manufacturing company. Its document volumes, historical versions and access rules shaped the proposed solution. The approved design included permission checks before composing answers, version checks, citations and customer acceptance testing.

The business supplied the use cases, organisational structure and access rules. Its internal IT function and managed service provider were involved, while we translated those inputs into a technical plan and estimated initial and ongoing costs. The recorded outcome was approval of the plan and authorisation to build, rather than verified production savings.

That experience shows why a review needs information from both the business and technical teams. In a comparable assessment, a reviewer would need to establish whose permissions apply and what evidence would demonstrate that restricted material stays outside an answer. A proposed design supplies requirements for testing; the completed test record would supply evidence about implementation.

Changes to the permitted use should trigger a check against the original decision. New users, different data sources or permission to take actions can alter the consequences even when the product name remains the same. The owner should identify which changes require fresh approval and who can recognise them during operation.

Scheduled reviews provide a separate opportunity to examine accumulated evidence. The useful interval depends on the use and the available monitoring, rather than a universal timetable. A review can examine incidents, failed checks, supplier changes and unresolved conditions alongside whether the original purpose still applies.

A decision to stop or restrict use also needs a practical operating arrangement. The record should identify who can make that change, how affected staff will be informed and how unfinished work will be handled. Those details help the team act on a review finding.

One well-defined use case is a manageable starting point for reviewing the process. Assemble its intended use, responsible people, existing evidence and unresolved questions, then record the decision and follow-up. The resulting gaps show what information or authority the next review needs.

Governance responsibilities should also be reflected in implementation scope. At Adaca, governance support is provided with partners within relevant implementation work, with responsibilities agreed for the engagement. Where the wider requirement is still unclear, our AI readiness guide covers the process, information and operating questions to establish before proceeding.