A.9.2 Processes for responsible use of AI systems: evidence

What A.9.2 processes for responsible use of AI systems require

A.9.2 asks the organization to define and document the processes it follows for the responsible use of AI systems. Picture the common trigger: a customer questionnaire asks how you govern AI, an auditor asks who approved a tool, or a team wants to adopt a new AI assistant and nobody can point to a written rule for saying yes. A.9.2 closes that gap by requiring a documented process that decides how AI is used, by whom, and under whose oversight. The risk it addresses is uncontrolled use. Staff adopt AI tools without review, use them for purposes nobody assessed, or feed them data they should not hold, and no accountable person sees it happen. The control is hard for two reasons. First, it covers in-house AI and third-party AI alike, including tools bought as features inside software the organization already runs. Second, a written procedure is not enough. The process has to be operated: requests get logged, approvals get recorded, and oversight owners review use on a schedule.

Within Annex A, A.9.2 sits under objective A.9 Use of AI systems, alongside A.9.3 Objectives for responsible use of AI system and A.9.4 Intended use of the AI system. A.9.2 is about the process itself: the steps, roles and records that govern use. A.9.3 defines the goals that use should serve, and A.9.4 checks that each system stays within its intended purpose. For a first step, list every AI system currently in use, including vendor features, and confirm who owns each one. Then draft an approval procedure covering how new uses are proposed, assessed and recorded, what acceptable use looks like, and who can stop a use that drifts. Confirm with your ISO/IEC 42001 certification body or auditor how they expect the process to be evidenced before you finalize it. Your own environment and governance structure determine the detail, so treat any generic template as a starting point.

Which AI uses and teams fall under A.9.2 scope

A.9.2 covers how the organization uses AI, so the first job is deciding which AI uses, systems and teams the process must govern. Each decision below changes how many approval paths, records and reviews the organization must maintain. The organization sets this scope in its statement of applicability under clause 6.1.3 and must justify any exclusion it makes.

In-house AI systems

Models, pipelines and AI features the organization builds or fine-tunes itself usually sit inside scope with the most documentation attached. Internal use cases need a recorded purpose, an owner, an approval step and a review trigger. Check whether internal experiments and proofs of concept are excluded by policy, and if so, whether that boundary is written down and justified. Confirm that a prototype cannot quietly move into production use without passing through the same approval path.

Third-party AI products and APIs

Hosted AI services that the organization calls through an API or subscribes to as a product generally fall under A.9.2 because the organization decides how they are used, even though a supplier runs the model. Each service needs an approval record, the permitted use cases and the people allowed to configure it. Ask procurement to route every new AI vendor or API key request through the same review that covers internal systems.

Employee use of AI tools

Staff who paste material into general-purpose chat assistants or browser extensions create AI use that often bypasses formal systems. The organization needs acceptable-use rules that name permitted tools, prohibited inputs and the escalation route for exceptions. This scope usually grows the amount of policy communication and monitoring work more than the technical build. Confirm whether unsanctioned tools are discovered, reported and handled through the same process as approved ones.

AI features embedded in purchased software

Many business applications switch on AI features through updates, such as summarization, scoring or automated suggestions. These features can enter use without a new contract or project, so they are easy to miss. The organization should review vendor release notes and admin consoles for newly enabled AI functions and decide whether each one is in scope. Record the decision for each feature rather than assuming that the software vendor's governance covers the organization's own use.

Teams with authority to approve new uses

The A.9.2 process needs named approvers, and the set of teams holding that authority determines who must be trained, who signs off and who is accountable when a use is refused. Business owners, security, privacy and legal reviewers often share the decision, so the approval matrix should state which combination is required for each risk level. Check that every team that can switch on an AI capability is either an approver or bound to the request process.

Data classes that flow into AI tools

The sensitivity of data sent to an AI system often matters more than the tool itself. Personal data, regulated records, confidential business information and source code each raise different approval conditions and different acceptable-use limits. The organization should map which data classes each approved use may receive and treat any new data class as a change that triggers review. Confirm that data restrictions appear in the approval record and in the rules staff see, not only in the privacy policy.

How an assessor tests A.9.2 and which evidence they request

This table lists the general steps an assessor takes when testing A.9.2, the evidence each step usually requests, and the findings that most often appear. Read it as a checklist of what to have ready before a stage 2 audit, not as a script the assessor will follow.

Test step	Evidence requested	Common findings
Confirm the documented use process exists and is approved	Approved process document for AI system use, version history, and the approver's name and role	Process exists only in draft, has no owner, or was never approved by management
Sample recent new AI uses and trace each to an approval record	Register of AI uses, approval tickets or minutes for a sample of recent new uses, and risk review outcomes	New tools in use with no approval record, or approvals given after deployment
Check acceptable-use rules are communicated and acknowledged	Acceptable-use rules, distribution records, training attendance, and signed acknowledgments by staff	Rules published but not acknowledged, or staff unaware of rules for tools they use daily
Check that oversight roles act on the process	Review minutes, escalation records, decisions to restrict or stop a use, and named oversight role assignments	Oversight roles defined on paper with no recorded reviews or decisions
Confirm third-party AI goes through the same path	Procurement intake records, vendor AI use approvals, and contract clauses covering AI use	SaaS features with embedded AI enabled without passing through the approval step
Check the process is kept current	Records of process reviews, changes after incidents or new regulations, and internal audit results	Process not reviewed since first issue, or changes not reflected in practice

Building the responsible use process step by step

The sequence below turns the A.9.2 requirement into a working process: an inventory of what AI is already in use, a named owner, an approval workflow, signed acceptable-use rules, defined oversight, a decision record, training and a first review cycle. Each step ends with a document or register that an auditor can inspect.

Inventory current AI uses
Start by listing every AI system the organization builds, buys, embeds or lets staff use, including AI features inside existing SaaS products and tools staff adopt without central approval. For each entry, record the owner, the business purpose, the data it touches, the users it affects and whether it is in-house or third-party. The output is an AI use inventory that becomes the baseline for every later step. It is done when business units have confirmed the list and no known use is missing.
Name the process owner
Assign one accountable owner for the responsible use process, with named deputies from legal, privacy, security and the business lines that use AI most. The owner should have authority to pause a use case, not only to report on it. The output is a short role statement that sets out responsibilities and reporting lines, and it should align with the roles defined under the A.3 controls. It is done when the owner has accepted the mandate in writing.
Draft the approval workflow for new uses
Define the stages a proposed AI use passes through before it goes live: the request form, a classification step, risk and impact review, sign-off by the right approvers and a go or no-go decision. The criteria at the classification step should come from the organization's AI risk and impact assessment, such as the sensitivity of data, the effect on individuals, the degree of automation and whether the use is customer-facing. The output is a written workflow document with decision criteria. It is done when a sample request can be walked through the workflow end to end.
Write acceptable-use rules
Write the rules that tell staff what they may and may not do with AI systems, covering approved tools, prohibited inputs such as certain categories of personal or confidential data, required human review of outputs, disclosure to customers and the handling of AI-generated content. Keep the rules specific enough that a staff member can apply them to a real task. The output is a signed acceptable-use rule set, with the approver, date and version recorded. It is done when every affected group has acknowledged the rules.
Define oversight and escalation
Set out who monitors approved uses, how often, and what triggers escalation, such as a complaint, a security finding, a change in the model or vendor terms, or output that breaches the rules. Define the decision path for pausing or withdrawing a use and who may authorize a restart. The output is an oversight and escalation procedure with named roles and contact routes. It is done when a tabletop walkthrough of one escalation has reached a documented decision.
Set up the record of decisions
Create an approval register that logs each request, the classification, the reviewers, the decision, any conditions attached and any later changes. Store the register and the rule versions in a system that keeps history and shows who changed what, so the organization can show an assessor how a given use was approved and later reviewed. The output is a maintained approval register and a version history for the workflow and rules. It is done when a sample decision can be traced from request to current status.
Roll out training
Train staff, approvers and managers on the acceptable-use rules, the approval workflow and how to escalate concerns. Tailor the content to roles, since people who request AI uses need different guidance from people who approve them. Record attendance and the version of material each person received. The output is a training record linked to the rule set version. It is done when every role in the inventory has completed its assigned training and gaps are followed up.
Run a first review cycle
Test the process against the live inventory. Check that every known AI use has an approval record, that the rules match what staff actually do, and that escalations were handled within the documented path. Record findings, assign corrective actions and update the workflow, rules or inventory where needed. The output is a review report with actions and an updated baseline. It is done when the findings are closed or have a documented owner and plan, and the review feeds the next cycle.

Which evidence passes A.9.2 and how to keep it current

An assessor testing A.9.2 looks for a documented process and proof that people actually follow it. The cards below cover the artifacts that show this, what each one must contain, and how to refresh it between audits so the record reflects current practice rather than the state at the last review.

Documented use process

The written procedure that defines how the organization decides to use an AI system, who takes part, which steps apply to in-house and third-party AI, and where each record is kept. Assessors check that the document names owners, sets entry and exit points for a use case, and matches what staff say they do. Review it on a fixed schedule and after any material change to tooling, vendors or regulation, and record each approved version with its date and approver.

AI use register

A living inventory of every AI system in use, with its business purpose, provider or internal owner, data categories involved and current status. Assessors compare the register against procurement records, cloud accounts and access logs to find uses that were never recorded. Reconcile the register against those sources at a set cadence, and flag any system that appears in logs but not in the register as a finding to resolve.

Approval records with rationale

For each new or changed use, a record showing who requested it, what risk review took place, the decision, any conditions attached and the rationale behind the decision. Assessors sample approvals and check that the approver had authority and that conditions were tracked to closure. Keep rejected requests too, since they show the process works. Revisit approved uses when their scope, data or vendor changes, because an approval granted for one purpose does not cover another.

Acceptable-use rules with acknowledgments

The rules staff and contractors must follow when using AI tools, covering permitted and prohibited inputs, handling of outputs and escalation paths. Assessors ask for the signed or electronically recorded acknowledgment of each person in scope and check that new joiners and contractors receive the rules before access is granted. Re-issue the rules when they change and require fresh acknowledgment, so the record shows which version each person accepted.

Oversight roles and review minutes

A documented assignment of who oversees each AI use, including who can pause it, and minutes from the reviews where that oversight took place. Assessors check that named individuals hold the roles, that they have the competence and time to perform them, and that review findings led to recorded actions. Hold reviews on a recurring calendar, keep the minutes with dated action items, and update role assignments whenever a person changes position or leaves.

Change history for the process

A version-controlled record of every revision to the use process, rules and registers, showing what changed, when, why and who approved it. Assessors use this history to confirm that the process has been reviewed and improved over time and that superseded versions remain retrievable for the audit period. Store these documents in a system that keeps prior versions and records authorship, and avoid replacing files in place, since overwritten documents cannot demonstrate what was in force on a given date.

How garak, Langfuse, XWiki and BookStack support A.9.2 evidence

Can XWiki keep the versioned A.9.2 process document and its change history?

Yes, XWiki can hold the written process for responsible AI use and keeps every change to a page under version control, recording what changed, when and by whom. Reviewers can compare any two versions and roll back to an earlier one, which gives an auditor a traceable record of when an approval step or acceptable-use rule was added or altered. It does not decide what the process should say, and it does not prove that people followed the process. The organization still owns the content, the approval sign-off and the review cadence. Confirm the license terms of LGPL-2.1-or-later with your legal team, and confirm that the XWiki edition and hosting model you plan to run fit your environment.

How does BookStack control who can approve AI use cases?

BookStack assigns abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. In practice, this lets process owners edit the AI use process, approvers hold rights to sign off on new use requests, and general staff keep read-only access. This separation is useful evidence that access to the governing documents is deliberate and limited. It does not replace a documented approval decision, and it does not show that approvers reviewed each request. Confirm the role model and permission inheritance against your own identity setup, and check the BookStack license terms (MIT) before you deploy it.

What does Langfuse record about how AI calls are made?

Langfuse captures traces of a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. For A.9.2, these traces support later review of how an AI system is actually being used, such as whether a use stays within the approved pattern or calls a tool the approval did not cover. Traces are operational evidence, not a policy. They do not tell you whether a use was approved, and they can contain sensitive data that needs handling rules. Confirm the MIT license terms, decide what content is logged, and confirm the deployment model fits your data residency needs.

How can garak results feed the risk review before a new AI use is approved?

garak probes language models for weaknesses such as hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. Reviewers can use these outputs as input to the risk assessment that precedes approval of a use case. The results are evidence of what was tested on a given model and configuration at a given time, not proof that the model is safe for a specific use. Results must be read against the intended use, and the approver still makes the decision. Confirm the Apache-2.0 license terms and whether the probes cover the failure modes your use case depends on.

Does using these open-source tools mean A.9.2 is satisfied?

No. Each tool produces part of the evidence an assessor might ask for, but A.9.2 concerns the organization's defined and documented processes for responsible use. Those processes need an owner, a written approval workflow, acceptable-use rules, a review schedule and records of decisions. The tools support those records: XWiki for the versioned document, BookStack for controlled access, Langfuse for runtime traces and garak for pre-approval testing. Whether that combination satisfies the control depends on the statement of applicability and how the organization runs its process. Confirm with your certification body or auditor which evidence they expect.

Can DeployOpen install and configure these tools for an AI governance evidence set?

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, so it can deploy these tools in your cloud account, data center or air-gapped network and connect them to your identity provider. It can also set up test runs with garak and configure Langfuse tracing as part of an agreed scope. DeployOpen does not write your AI use policy, decide which uses are approved, or issue any audit report or certificate. Engagements are fixed-scope, and the written scope sets the deliverables and timelines before work starts.

What ongoing effort do these tools add after deployment?

Most of the cost sits in one-time setup and in the recurring work of keeping the tools running and the evidence current. Recurring items include upgrades, backups, access reviews in BookStack, log retention decisions for Langfuse, periodic garak runs on models in use, and the review cycle for the XWiki process. Effort rises with the number of AI systems, the number of approvers and the volume of trace data. Ask any implementation partner for a written list of recurring tasks, who performs each one, and how the work is handed over, and confirm the upkeep your own staff can absorb.

What meeting A.9.2 costs in money and effort

This table compares the cost components of implementing A.9.2, who is paid for each, whether it is one-time or recurring, what drives it, and how to keep it down. Read it as a checklist for scoping and for reviewing a quote, since no fee or duration is stated here.

Cost component	One-time or recurring	What drives it	How to reduce it
Policy and process drafting for responsible use	One-time, then periodic review	Number of AI uses in scope, legal and sector rules, how many business owners must sign off	Start from an existing acceptable-use or software policy, limit the first scope to current AI uses, and ask the drafter to reuse your templates
Tooling and hosting for the use register and documentation	Setup one-time, hosting and administration recurring	Open-source tools such as XWiki or BookStack have no license fee, but they need servers, backups, upgrades, identity integration and an administrator	Reuse existing collaboration infrastructure, confirm hosting and admin ownership before build, and ask for backup and upgrade work to be named in the quote
Engineering time to wire intake into existing workflows	One-time, with changes as workflows change	Number of ticketing, procurement, cloud and CI/CD systems the approval gate must touch	Map the request path first, then connect one tool at a time rather than building a single bespoke portal
Review and approval time from owners	Recurring	Number of approvers, frequency of new AI requests, and whether approvals are re-checked when a use changes	Define approval tiers by risk so low-risk uses follow a short path, and set a fixed review cadence for owners
Evidence upkeep (logs, records, change history)	Recurring	Volume of traces and logs, how often uses change, and how much history must be retrievable	Set retention rules early, export only the records an assessor will sample, and automate capture where the tooling allows
External review or assessment	Recurring at each assessment cycle	Scope of the management system, whether a readiness review is bought before the certification audit, and the certification body's own fees	Ask for a readiness review scoped to A.9.2 and its linked clauses, and keep the implementation partner and the certification body separate
Auditor sampling time	Recurring at each audit	How many AI uses the auditor samples, how easily records can be found, and how well approvals are linked to each use	Keep a single index of approved uses with links to approvals, owner sign-offs and review dates so sampling takes less time

What your team keeps and what a partner or auditor does

Your organization owns A.9.2 in full. The process you define must name the people who decide which AI uses are approved, restricted or refused, and who accept the residual risk that remains after controls are applied. A partner can draft the process and an auditor can test it, but neither can make those decisions for you. Clause 6.1.3 also places the statement of applicability with the organization, so the justification for including or excluding each Annex A control is yours to write and defend.

Approval authority: Name the role that can approve a new AI use, such as a business owner working with a risk function, and record the limits of that role.
Acceptable-use rules: Decide what staff may and may not do with AI tools, including which data classes can enter a prompt, and approve the final wording.
Risk acceptance: Record who accepts residual risk for each approved use, under what conditions, and when the acceptance is next reviewed.
Oversight cadence: Set who reviews the use register, how often, and which events trigger an early review, such as a change of model vendor or a new data source.
Ownership after handover: Make sure staff can maintain the register, the rules and the approval log without outside help.

Before any engagement starts, confirm that a named executive can point to the record of each approval decision and each accepted risk in your own systems.

Where A.9.2 processes usually fail and how to close each gap

A.9.2 processes tend to fail at the point where documented intent meets daily practice. The cards below cover six gaps that assessors commonly probe, each with the fix and the record that shows the fix is working. Use them as a self-check before an assessor or customer asks for evidence.

Process exists only on paper

The organization has a written approval process for new AI uses, but no record shows that any use was actually approved through it. Close the gap by routing every new use through a single intake form, with a named approver and a dated decision. Evidence that the fix works is a sample of recent approvals, each showing the request, the risk review and the decision. Ask whether the policy has been followed for systems already in production, not only for new ones.

Shadow AI tools missing from the register

Staff adopt browser-based assistants, plug-ins and API keys that never reach the AI inventory, so the process never sees them. Close the gap with a recurring discovery step that compares network, expense and identity data against the register, plus a short rule that any new AI tool needs an intake ticket. Evidence is a dated reconciliation showing discovered tools, their disposition and the owner who acted on each one.

Third-party AI outside the process

AI features arrive inside purchased software, vendor SaaS upgrades or contracted services, and procurement treats them as ordinary software. Add an AI question to vendor onboarding and renewal, so that a supplier adding AI functions triggers the same review as an internal use. Evidence is a contract or onboarding record for each AI-enabled supplier that shows the review outcome and the data and use terms accepted.

Acceptable-use rules nobody acknowledged

Acceptable-use rules for AI sit in a policy library that staff never open, so a user's first exposure is an incident. Require each user of an approved AI system to acknowledge the rules before access is granted and again when they change materially. Evidence is an acknowledgment log tied to user identities, with the version of the rules each person accepted and the date. Confirm that access provisioning checks this log.

Oversight roles without named reviewers

The process assigns human oversight to a function such as risk or the AI committee, but no individual is named for each system, and reviews lapse when someone leaves. Name a primary and a backup reviewer for every approved use, with the review frequency and escalation path written next to the name. Evidence is the current reviewer roster and completed review records that show the named person signed off within the set cycle.

No record of process changes

The approval workflow, risk criteria and acceptable-use rules are edited in place, so an auditor cannot tell which version applied when a decision was made. Keep the process documents under version control, with each change recording what changed, who approved it and the effective date. Evidence is the revision history, plus a decision record that cites the process version in force when the decision was taken. Confirm that the platform that holds these documents keeps this history.

What buyers ask about A.9.2 cost, effort and outside help

Can we write our A.9.2 process ourselves?

Yes, the organization owns its controls, so its own staff can define and document the processes for responsible use of AI systems. A.9.2 asks for defined and documented processes, which usually means an approval path for new AI uses, acceptable-use rules, and named oversight roles for both in-house and third-party AI. Teams that already run change management or vendor onboarding can extend those workflows rather than start from nothing. The harder part is getting the right people to agree on the rules and to follow them. Confirm with your certification body or auditor which evidence they expect before you finalize the design.

How much effort does A.9.2 need from our own staff?

The effort sits mainly with the people who approve AI use, own AI systems and operate the review workflow, and it is largely one-time for the design and recurring for review. Expect time from a governance owner, a security or privacy reviewer, the business owners of each AI use, and whoever maintains the records. The recurring load depends on how many AI uses the organization approves and how often they change. Ask any partner to estimate effort in person-days for each role in the written scope, so you can see which staff time is needed before work starts.

What drives the cost of A.9.2 implementation?

The cost depends on the number of AI systems in use, how many third parties supply them, and how much existing process and tooling can be reused. Organizations with many AI uses across business units need more intake, review and recordkeeping than a single team with one tool. Heavy in-house AI development adds design review and testing evidence, while third-party AI adds contract and supplier checks. Costs fall when approval, acceptable-use and oversight rules reuse existing policy and ticketing systems. Costs rise when records must be rebuilt from scratch or reviews must be run by hand.

What must stay in-house for A.9.2?

Decisions about which AI uses are approved, who is accountable for them, and what the acceptable-use rules say must stay with the organization. An outside partner can draft process documents and set up the records, but it cannot own the decisions or accept the residual risk. The people who sign off on new AI uses should be employees with the authority to stop a use. Independent certification bodies decide whether the system meets the standard, so the auditor relationship also stays separate from any consultant who helped build the process.

What should we ask an implementation partner to deliver for A.9.2?

Ask for a written scope that lists each deliverable, the systems it touches and the evidence it produces. Useful deliverables include a documented intake and approval process for new AI uses, acceptable-use rules, a register of AI uses with named owners, oversight role definitions, and records that show past decisions. Ask how the partner will hand over the documents and whether training for approvers is included. Also confirm what the partner will not do, such as issuing reports or certifications, and ask for the timeline and staff time it expects from your side.

How does A.9.2 connect to the NIST AI RMF crosswalk for GOVERN 4.1, MAP 4.1 and MANAGE 1.1?

The NIST crosswalk maps three AI RMF items to B.9.2, the implementation guidance for A.9.2: GOVERN 4.1 on a safety-first mindset, MAP 4.1 on technology and legal risks of components, and MANAGE 1.1 on the decision whether to proceed with a system. In practice, the approval step for a new AI use is where those ideas become a record. A use approval should show that safety was considered, that legal and component risks were mapped, and that someone decided to proceed. Read the crosswalk directly and check it against your own risk process, because it is a mapping and does not replace the standard.

How long does it take to get A.9.2 processes in place?

The duration depends on how many AI uses need review, how mature existing approval workflows are, and how quickly decision owners can be assigned. Organizations that already run structured change or vendor review usually need less time than those starting from informal approvals. The scope agreed in writing sets the timeline, so ask for milestones tied to deliverables rather than a single end date. Confirm the expected duration with your partner and your certification body before committing, since neither can promise an outcome.

How DeployOpen scopes and prepares A.9.2 evidence

DeployOpen helps organizations set up the systems, records and workflows that show how AI systems are approved, used and overseen under A.9.2. We prepare the operating side of the process and its evidence inside your own infrastructure, while the organization keeps ownership of its controls and an independent auditor or certification body makes any certification decision.

How we scope

We agree a written scope listing which AI systems, in-house and third-party, fall under the A.9.2 use process.
The scope names the approval, acceptable-use and oversight records the organization already has and what is missing.
Engagements are fixed-scope, so deliverables and timelines for A.9.2 are agreed in writing before work starts.

How we build

We configure self-hosted tools in your environment to hold the approval requests and acceptable-use rules for AI systems.
We set up logging of AI calls and reviewer actions so oversight decisions can be traced to a named person and date.
We test the workflow with your staff against the written process to confirm approvals and escalations actually happen.

How we hand over

We document the responsible use process, approval steps and roles in a version-controlled wiki that your team owns.
We deliver an evidence map linking each A.9.2 process statement to the record, log or report that shows it operating.
We walk your compliance and engineering leads through the handover so they can maintain the evidence after the engagement.

How we support

Ongoing support, upgrades and continuous testing of the AI use workflows are available as a retainer.
Retainers can cover periodic reviews of approval records and updates to acceptable-use rules as AI systems change.
Ask us to confirm which evidence your chosen auditor expects for A.9.2 before the scope is signed.