A.9.4 Intended use of the AI system: evidence guide

What A.9.4 intended use of the AI system asks for

If an audit is coming or an AI system is already live, A.9.4 asks you to show that each system is used according to its intended uses and its accompanying documentation. The control is about keeping real use inside the boundaries you defined when you built or bought the system, and being able to prove it. Use rarely drifts on purpose. A marketing team points a customer-support chatbot at contract review, a data team feeds it a new data set, a vendor quietly enables a feature that the documentation never covered, or staff find a workaround that gets them a result faster. Each step looks small, but the system is then making decisions its risk assessment never considered, and the documentation no longer describes what it does.

The control is hard to run for three reasons. Intended use is often written once, in a design document or a model card, and never updated as the system changes. Usage data sits in several places, such as application logs, vendor consoles and shared drives, so no one sees the whole picture. And the people who notice drift are rarely the people who approve new uses. The NIST AI RMF crosswalk for ISO/IEC 42001, contributed by Microsoft, maps A.9.4 to MAP 4.1, MANAGE 1.1 and MANAGE 2.4. That is a crosswalk, not an endorsement by NIST, and it is a useful starting point for showing where your existing risk work already touches the control.

Start by confirming, for each in-scope system, the written intended-use statement, the documentation users receive, and who owns the boundary. Then decide how you will detect use outside that boundary, such as reviewing traces, audit logs or access records, and what you will do when you find it: restrict the feature, update the documentation and risk assessment, or disable the system. Ask your auditor which evidence they expect for this control before you build it, since the required depth depends on the system's risk and your own statement of applicability.

Which AI systems and uses fall under intended use

Intended use only means something once the organization decides which AI systems, features and user populations the statement covers. The cards below set out the scoping choices that change what A.9.4 requires and what evidence an assessor will expect. The organization owns the statement of applicability under clause 6.1.3, including the decision to include or exclude A.9.4, and should record its reasoning for each system.

In-house models and fine-tuned systems

For a model the organization trains or fine-tunes, the organization writes the intended-use statement itself, so it carries the full burden of defining purpose, users, input types and excluded tasks. Record the training objective, the evaluation results that support each intended use, and the known limits found during testing. Check whether a model retrained for a new purpose has a new intended-use statement, because reuse outside the original purpose is the most common drift. Ask who approves a change in purpose before the model is redeployed.

Third-party AI features inside SaaS

When a SaaS product embeds an AI feature, the vendor's documentation defines the stated purpose, but the organization defines how its staff actually use it. Collect the vendor's intended-use documentation, terms and release notes, then compare them with the tasks your teams assign to the feature. A feature marketed for summarizing support tickets may be used to draft legal responses. Record the gap, decide whether it is acceptable, and confirm with the vendor where its documented purpose ends.

Internal copilots and staff assistants

An internal copilot connected to email, document stores or code repositories has an intended use set by the configuration as much as by the model. Document which data sources, tools and permissions the copilot receives, and which tasks it is approved to support. Monitor prompts and outputs for requests outside the approved set, such as personnel decisions or access to restricted records. Changes to connectors or permissions should trigger a review of the intended-use statement.

Customer-facing chat and public interfaces

A customer-facing chat assistant has the widest intended-use exposure because the public can attempt any request. Define the permitted topics, the escalation path to a human, and the disclaimers shown to users, then state these in the documentation that accompanies the system. Testing should cover out-of-scope requests such as legal advice, account changes or medical questions. Evidence should show that out-of-scope attempts are logged and that the system declines or hands off as documented.

AI use by staff outside approved tools

Staff often use public AI tools that the organization never assessed, which places that use outside any intended-use statement. Decide whether the scope covers only approved systems or also unsanctioned use discovered through monitoring, and document the answer. Evidence can include network or browser logs, data loss prevention alerts and a clear acceptable-use rule. Confirm with your security and legal teams which monitoring is permitted in your jurisdiction before you rely on it.

Configuration changes that alter purpose

The organization's own configuration can change an AI system's purpose even when the model and vendor stay the same. Prompts, retrieval sources, tool access, thresholds and user roles all shape what the system is used for. Decide whether the intended-use statement covers only the vendor's stated purpose or also the organization's configured purpose, and record which one governs. Assessors will expect the configured purpose to be documented, versioned and tied to a change record.

How an assessor tests intended use of the AI system

This table compares what an assessor typically examines for A.9.4 across three areas: sampling documented intended uses, reviewing usage monitoring, and checking how out-of-scope use is detected and handled. Read each row as a question the organization should be able to answer with dated records before the assessment starts, and treat the statement of applicability row as the point where the justification for the control is judged.

Area	What the assessor does	Evidence requested	Common findings
Documented intended uses	Selects a sample of AI systems and compares each documented intended use and its accompanying documentation against the live configuration, prompts, access grants and connected data sources.	Intended-use statement per system, version history, user documentation and the configuration export that matches it.	Intended-use statements are generic, predate a configuration change, or do not mention integrations added later.
Live configuration match	Checks whether the running system permits only the uses described, such as allowed tools, data classes, user groups and output channels.	Configuration exports or infrastructure-as-code history, change tickets linked to scope changes, and access reviews.	Features enabled in production that the documentation never mentions, or test settings still active after release.
Usage monitoring records	Reviews logs over a defined period to see what users actually asked the system to do and whether that matches the documented purpose.	Request logs or traces with timestamps, user identifiers and tool calls, plus the review cadence and who signed off each review.	Monitoring exists but nobody reviews it, or logs are retained for too short a window to cover the audit period.
Out-of-scope use detected and handled	Looks for a recorded case where use drifted outside scope, then follows it through detection, containment, decision and follow-up.	Alerts or flagged events, incident or exception records, the disposition decision, and evidence the system was restricted or disengaged.	No out-of-scope events in the record at all, which the assessor may read as absent monitoring rather than absent misuse.
Mechanisms to disengage	Tests whether authorized staff can restrict, suspend or switch off the system when use is inconsistent with its purpose, and whether that path has been exercised.	Runbook, kill-switch or feature-flag configuration, and a test or drill record with date and outcome.	The mechanism exists on paper, but no one holds the access needed to use it or the procedure was never tested.
Statement of applicability	Checks that the statement of applicability includes A.9.4 and gives a justification consistent with the organization's AI use, rather than a bare inclusion or exclusion.	Statement of applicability entry, the risk or scope reasoning behind it, and the systems it covers.	Control excluded without justification, or justification that describes a policy the organization never implemented.
Link to A.9.2 and A.9.3	Confirms that approved uses and objectives set elsewhere in the use controls match the intended uses recorded for each system.	Approval records for new uses, the objectives register, and cross-references between those records and the intended-use statements.	Approvals recorded for a use category that differs from the wording in the system's own documentation.

Implementation sequence for intended use controls

This sequence turns A.9.4 from a policy statement into a working cycle: every AI system has a documented purpose, a boundary, monitoring that can see drift, and a tested response when use leaves that boundary. Each step names the record it produces so an assessor can trace the control from intent to evidence.

Inventory every AI system and its owner
Start with a complete register of AI systems in use, including those built in-house, those embedded in purchased software and those accessed through external APIs or hosted models. Record a named business owner and a technical owner for each entry, plus the environments where it runs. The output is an AI system inventory that every later step references. The step is done when someone outside the project team can pick any system from the register and identify who answers for it.
Write intended-use statements and boundaries
For each inventoried system, the owner drafts an intended-use statement that describes the purpose, the users, the decisions or outputs the system supports and the populations or data types it is meant to handle. The same owner then writes the use-case boundary, listing adjacent uses that are out of scope and explicit prohibited uses. Risk, legal and the affected business function review the drafts. The output is an approved use register. The step closes when each entry has a version, an approver and a review date.
Align vendor documentation with internal statements
For systems supplied by third parties, collect the provider's documentation, instructions for use, usage policies and any stated limitations. Compare each limitation against the internal intended-use statement and boundary, and record gaps where the organization's planned use is broader than what the provider describes or supports. Where a gap exists, either narrow the internal use, obtain written clarification from the provider or open an impact assessment. The output is a reconciliation record per supplier system. The step is complete when every gap has a recorded decision.
Configure monitoring for use outside the boundary
Define the signals that show a system is being used outside its approved boundary, such as new user groups, unapproved data sources, prompts or requests that fall into prohibited categories, or outputs sent to unexpected destinations. Enable the logging and tracing the platform supports so these signals can be reviewed, and confirm what each log captures and how long it is retained. Keep the logging configuration under change control. The output is a monitoring specification that maps each boundary rule to a detection source. The step is done when a test event in each category appears in the logs.
Define the drift response runbook
Write the procedure that applies when monitoring or a review finds use outside scope. It should set out the response levels: restrict the use (for example, by limiting access or disabling a feature), escalate to the accountable owner and the governance function, disengage or deactivate the system when use cannot be brought back within bounds, or formally re-scope the use through an impact assessment before it continues. Name who decides at each level and how each decision is recorded. The output is a drift-response runbook. The step is complete when each response level has a named decision owner and a recorded example of how it would be invoked.
Test the process once before the audit
Run a controlled exercise: pick at least one system, introduce a deliberately out-of-scope use in a non-production environment, and follow the monitoring and runbook end to end. Record when the event was detected, who was notified, which response level was chosen, the action taken and whether the register was updated. Correct any step that did not work and rerun the affected part. The output is a dated test record with findings and remediation. An assessor will expect to see this kind of evidence showing the control operates, not only that it is documented.
Keep the register current through change
Connect the intended-use register to the organization's change process so that new models, new features, new user groups and new data sources trigger a boundary review before release. Schedule periodic reviews of each entry and record the outcome of each review. Feed monitoring results and drift events back into the register and the runbook. The output is a change-linked review log showing that intended-use statements reflect how systems are actually used. The step is ongoing and is verified by sampling recent changes against their register entries.

Evidence that shows intended use is controlled

A.9.4 is tested by evidence that ties each AI system to a defined purpose and shows that actual use stays inside it. The cards below cover the records that establish the boundary, the vendor material it rests on, the monitoring that checks use against it, and the change records that show what happened when use moved outside it.

Intended-use register per system

A register entry for each AI system that states its intended purpose, the users and business processes it supports, the decisions it informs or makes, and its owner. Auditors use it as the baseline for every other piece of A.9.4 evidence, so an AI system missing from the register is a gap before any log is reviewed. Check that every system in the AI inventory has an entry, that third-party AI tools used by staff are included, and that the owner named can explain the stated purpose. Confirm the review cadence and owner with your own governance policy, since ISO/IEC 42001 does not set one.

Use-case boundary and prohibited-use statements

Written boundaries that describe what the system is for, the input types and populations it is meant to handle, and the uses that are forbidden, such as sole reliance for decisions the organization has excluded. Prohibited uses should be specific enough that a reviewer can recognize a violation in a ticket or log. Check that the statements match what the system is configured to accept and that users can reach them from the tool itself or from the approval workflow. Set the owner as the accountable business owner, and confirm the review trigger in your own policy.

Vendor documentation and instructions for use on file

The provider's documentation that states what the model or product was designed for, its known limitations and the conditions under which it should not be used. This is the reference point for judging whether a deployment is a supported use. Keep the version that applied at the time of each approval, since documentation changes over time. Check that the file records the source, the version or date received, and any use restrictions in the vendor terms. Ask your procurement or third-party owner to confirm the update process with each vendor, because your organization cannot assume the vendor will notify you of changes.

Monitoring records and logs against the boundary

Records showing actual use compared with the boundary, such as request traces, audit trails and access logs filtered for out-of-scope activity. Self-hosted tooling can capture this evidence: Langfuse traces record inputs, outputs, tool calls and metadata for each request, and audit trails in Nextcloud or OpenBao can show who accessed an AI-connected system and when. Check that logs cover the systems in the register, that retention matches your policy, and that someone is assigned to review them. Confirm with your security team how sensitive values are handled in stored logs before you grant wide access to them.

Drift tickets with dispositions

Tickets opened when monitoring, a user report or a review shows use outside the stated purpose. Each ticket should record what drifted, the risk it raised, the decision taken (stop, restrict, approve as a new use, or accept with conditions), who decided, and when the outcome was verified. Auditors often sample these tickets to see whether the process works in practice, so closed tickets without a disposition are a common finding. Check that tickets link back to the register entry and boundary statement they relate to, and confirm the escalation path with your incident and risk owners.

Records of re-scoping

Records that show when an intended use was formally changed, widened or narrowed, such as an updated register entry, a revised boundary, a new impact assessment or a re-approval. Re-scoping should happen before the new use goes live, not after drift is discovered. Each record should state the old and new purpose, the reason, the approver and the controls added. Check that re-scoping triggers are written into your change process so that a new use case cannot reach production without passing through this record. Confirm with your AI governance owner how re-scoping links to the approval process described under A.9.2.

What meeting A.9.4 costs in money and effort

This table lists each cost component of keeping AI use within intended purpose, who typically carries it, whether it is one-time or recurring, and what pushes it up or down. No supplied figures exist for these costs, so use the table to structure a request for a written scope and quote rather than as a budget.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Writing intended-use statements	Internal product or system owners, with compliance review	One-time per system, then recurring on change	Up with the number of AI systems and their use cases. Down with one shared register template reused across systems.
Building monitoring and logging	Engineering or platform team, or an implementation partner under a fixed scope	One-time build, recurring upkeep	Up with the number of model endpoints, tools and data flows to instrument. Down with self-hosted open-source logging such as Langfuse or Nextcloud audit logs where they fit.
Licenses or hosting for monitoring tools	Software vendors for commercial tools; infrastructure budget for self-hosted tools	Recurring	Up with commercial per-seat or per-volume pricing and log retention periods. Down with self-hosted tools inside the organization's own infrastructure, though hosting and storage still recur.
Drift reviews against intended use	Control owner and system owners, time set in the review calendar	Recurring	Up with the number of systems and how often their inputs, users or third-party models change. Down with review triggers tied to change management.
External testing for misuse	Security testing provider, under a written scope	Recurring or per engagement	Up with the number of AI systems, agent tool access and the depth of misuse testing requested. Down with a narrower, risk-ranked scope agreed in writing.
Auditor sampling time	Independent auditor or certification body, per its fee terms	Recurring at each audit cycle	Up when records are scattered or undated. Down when each system has a current statement, a dated review and retrievable logs.
Corrective action when use drifts	Engineering, product and legal owners	Variable, occurs when drift is found	Up when no disengagement path exists and systems must be rebuilt. Down when the override or shutdown mechanism is designed in advance.

Self-hosted open-source tools that support intended use evidence

Intended use evidence comes from three things: a defined boundary for each AI system, records of how it is actually called and used, and tests that show when use strays. The tools below each produce one part of that picture inside your own infrastructure. None of them decides whether a use is in scope, and none of them is an audit result on its own.

garak for misuse probing

garak is an Apache-2.0 scanner that probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity and jailbreaks. For A.9.4 it supports evidence that a deployed model still behaves within the limits you documented, because its JSONL report records every attempt and evaluation and its hit log lists attempts that found a weakness. It does not prove that your application enforces the intended-use boundary, since it tests the model, not your workflows or access rules. Confirm which probes match your use case and review the license terms before deployment.

Langfuse traces of AI use

Langfuse is an MIT-licensed observability platform. Each trace captures the operations in a request, including LLM calls, retrieval steps, tool executions and custom logic, along with timing, inputs, outputs, token usage and metadata. For A.9.4 this is the record that shows how a system was actually used, so you can compare real calls against the documented purpose and spot unexpected tools, data sources or user patterns. It does not show whether a use was approved, and capturing prompts may itself create personal data handling duties. Confirm what your configuration stores and for how long.

Nextcloud admin_audit logging

The admin_audit app in Nextcloud, licensed AGPL-3.0-only, logs additional event information to audit.log in the data directory, or to a path you set with logfile_audit. Where an AI assistant or document workflow runs on Nextcloud, these entries show administrative and access events that bear on whether a feature is being used by the people and groups it was approved for. It does not capture the content of AI prompts or outputs, and it does not decide whether a use is in scope. Confirm which events your version logs and protect the log file from modification.

OpenBao audit device records

OpenBao audit devices, under the MPL-2.0 license, keep a detailed JSON log of every API request and response, including errors. Most sensitive values are hashed with HMAC-SHA256. For A.9.4 this shows which identities requested secrets, keys or credentials that AI systems depend on, and when, so you can check that access stayed with the services and people approved for a given use. It does not show what the AI system did with those credentials, and hashed values must be correlated carefully. Confirm the audit device configuration and where logs are stored before relying on them.

Who owns intended use and what partners can take on

The organization owns A.9.4 because only it can decide what each AI system is for, who may use it, and when it must stop. An intended-use statement is a business and governance decision. It has to reflect the purpose the organization chose, the users it accepts, the data it allows and the conditions under which the system is out of scope. Those decisions stay with the organization even when a partner builds the records that hold them.

Intended-use statements: Write and approve a statement for each AI system that names its purpose, permitted users, permitted inputs and excluded uses.
Boundary approval: Sign off on use-case boundaries, including what happens when a team wants a new use that falls outside the statement.
Disengagement decisions: Decide who can suspend, restrict or switch off a system when use drifts outside scope, and document that authority.
Statement of applicability: Sign the clause 6.1.3 statement of applicability, including the justification for including or excluding A.9.4.
Accountable owner: Name a person whose role covers review of misuse findings and closure of drift incidents.

Before engaging anyone, confirm that a named owner can make and sign these decisions without the partner in the room.

Where intended use controls usually fall short

Most intended use statements look complete on paper and then drift in practice. The gaps below share one root cause: the documented boundary for each AI system is not tied to a named owner, a configuration record or a review routine. Each card describes a gap an assessor is likely to probe and the closure step that resolves it.

Vendor copy passed off as intended use

Intended use statements often reuse the marketing description of a product, which states what the vendor hopes the tool does rather than how your organization configured it. A.9.4 expects use to follow the intended uses and the accompanying documentation, so a statement that names capabilities you never enabled gives an assessor nothing to test. Rewrite each statement from the deployed configuration: the permitted tasks, the data classes allowed as input, the users and the decisions the output may inform. Then check it against the vendor's own documentation and record any uses the vendor excludes.

No named owner per system

An AI system with no accountable owner has no one to approve a new use, notice drift or retire the system when its purpose changes. Teams frequently assume the sponsoring business unit owns the boundary, while IT owns the tool, so neither reviews the scope. Assign one named owner per AI system in the inventory, with a deputy, and record that the owner signed the intended use statement. Ask the owner to confirm the boundary at each review cycle, not only at launch.

Use logged but never reviewed

Teams often turn on prompt logging, API audit trails or application event logs and then never look at them against the intended use statement. The records exist, but no one has defined which events indicate out-of-scope use, such as a customer-facing assistant receiving HR questions or a summarization tool processing regulated records. Define a short list of misuse indicators for each system, assign a reviewer, set the review frequency and keep a dated record of each review and its findings. Confirm that the logging platform retains the events long enough for your review cycle.

Drift found but not re-scoped

When a team notices that a tool is being used for a purpose outside its documented scope, the usual response is an informal chat, and the documented boundary stays unchanged. An assessor will compare what staff actually did with what the record says, and the gap becomes a finding. Treat every confirmed out-of-scope use as a change event: stop or contain the use, assess the risk through your impact process, then either update the intended use statement with approval or disable the use. Keep the ticket, decision and approver together as evidence.

Configuration changes bypassing the register

Prompt templates, system instructions, retrieval sources, tool permissions and model versions are often changed directly in a console or repository without updating the register of uses. Each change can widen what the system does, even when the stated purpose stays the same. Bring these artifacts under version control, require a review step for changes that alter scope, and compare the deployed configuration with the intended use statement on a schedule. Confirm with your platform team which changes trigger a re-scope review.

Questions buyers ask about intended use of the AI system

How much effort does A.9.4 take for a team with only a few AI systems?

For a small team, A.9.4 is mostly documentation and a repeatable check, not heavy engineering. The organization needs a written intended-use statement for each system, the vendor or internal documentation that describes its proper use, and a short list of out-of-scope uses that staff must not pursue. The effort grows with the number of systems, the number of user groups and how often use cases change. No supplied fact gives a duration or headcount, so ask any advisor to estimate effort from a written list of your systems and their current documentation.

Can we run A.9.4 ourselves without outside help?

Yes, many organizations do. The control asks you to use each AI system according to its intended uses and accompanying documentation, so the people who own the business process and the system can write and maintain that boundary. Outside help is most useful when the scope is unclear, when you lack a staff member who can read vendor documentation critically, or when you need someone to prepare monitoring evidence. Under ISO/IEC 42001, the organization owns its controls. An implementation partner can prepare systems and evidence, but only an independent certification body issues a certificate.

What does A.9.4 need from engineering and compliance staff?

Engineering staff need to make intended use technically visible, for example by restricting features to approved workflows, logging which system and user performed each request, and flagging requests that fall outside the approved pattern. Compliance staff need to own the intended-use statements, approve any change in purpose, and decide what happens when use drifts. Both groups should agree on who reviews misuse signals and how often. Clear ownership matters more than tooling, because an assessor will ask who acts on a finding and how that action is recorded.

How long does preparing for A.9.4 usually take?

No researched duration is available for A.9.4, and the time depends on how many AI systems are in scope, how well their intended uses are already documented and whether monitoring exists. Ask for a written scope before agreeing to any timeline. A good scope names each system, the controls being prepared, the evidence to be produced, the people who must review it and the deliverables. Fixed-scope engagements agree these items in writing before work starts, which makes timelines easier to compare across proposals.

Can we exclude A.9.4 in the statement of applicability?

Possibly, but only with a documented justification. Clause 6.1.3 requires a statement of applicability that lists the Annex A controls the organization needs and justifies including or excluding each one. An organization that uses AI systems will rarely have a sound reason to exclude intended-use controls, because use is where the risks of misuse and scope drift arise. If you do propose an exclusion, the justification must be specific and tested by your certification body. Confirm the exact wording expectations with your chosen certification body before relying on any exclusion.

How does intended-use evidence link to the EU AI Act or NIST AI RMF?

A customer asking this usually wants to know whether your documented use boundaries and monitoring will support their own risk review. The NIST AI Resource Center crosswalk, contributed by Microsoft and not endorsed by NIST as an official mapping, links B.9.4 to AI RMF MAP 4.1, MANAGE 1.1 and MANAGE 2.4. The European Commission says ISO/IEC 42001 does not match the EU AI Act quality management system, so present ISO evidence as supporting material, not as proof of AI Act compliance. Confirm specific EU AI Act obligations with counsel or the relevant regulator.

What evidence shows that an AI system stayed within its intended use?

Assessors typically look for the approved intended-use statement, the version history showing who approved it, and records of monitoring that compare actual use against that statement. Logs are central. Langfuse traces can record inputs, outputs and tool executions for LLM applications, Nextcloud's admin_audit app writes event information to audit.log, and OpenBao audit devices keep JSON logs of API requests. Garak can probe a language model and write a JSONL report and hit log, which supports testing for misuse paths. Confirm each platform's current capabilities in your own environment before treating it as evidence.

How DeployOpen prepares intended use evidence

DeployOpen helps organizations prepare the systems, records and evidence behind A.9.4 Intended use of the AI system inside their own infrastructure. The organization still owns its controls and decides what each AI system is for, and an independent auditor or certification body is the only party that assesses conformity and issues a certificate.

How we scope

Agree in writing which AI systems, use cases and environments fall under the A.9.4 review.
Record each system's intended uses and the accompanying documentation that defines them.
Confirm which parts of the work the organization keeps in-house and which DeployOpen prepares, before work starts.

How we build

Configure logging of prompts, outputs and tool calls so out-of-scope use can be detected and traced.
Set up scheduled security testing of language model systems to check for misuse paths beyond intended use.
Define escalation steps that let the organization suspend or disengage a system when its use drifts outside scope.

How we hand over

Deliver written use-case boundaries, monitoring procedures and drift-response runbooks for the organization to approve.
Provide evidence packs that map logs, test reports and review records to the A.9.4 control and its statement of applicability entry.
Document configuration, ownership and retention settings so the organization's own staff can operate the controls after handover.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
Ongoing support, upgrades and continuous testing are available as a retainer for systems that keep changing.
Ask any prospective partner to confirm what they prepare, what the organization must approve, and which assessor will review the evidence.