AI, Machine Learning, and Generative AI for Auditors

An organization can say it has “five AI solutions” while describing five very different control environments. One uses fixed rules to automate an approval. Another assigns a risk score learned from historical data. A third drafts text. A fourth retrieves internal policies before answering. A fifth can open a case, send a request, and update a business system without waiting for a person to execute every step.

Calling all five “AI” may be acceptable in an executive presentation. It is not enough for an audit.

The practical point is simple: before auditors assess the controls around an AI system, they need to understand what kind of technology they are looking at and how that changes the risk surface. Auditors do not need to know how to train models. They do need to distinguish deterministic logic from learned behavior, prediction from generation, retrieval from model knowledge, and recommendations from actions.

ISO/IEC 22989:2022 was developed to establish common AI concepts and terminology. For auditors, that precision is not academic. It helps prevent a common failure in scoping: testing the wrong controls because the technology was classified too loosely.

AI is a family of technologies, not one technology

The first useful distinction is between automation and artificial intelligence. A rule that says “invoices above 50,000 require a second approval” can automate a decision without learning anything from data. It is deterministic software: given the same inputs and configuration, it should follow the same logic.

Artificial intelligence is broader. Within AI, many systems auditors encounter use machine learning (ML): models learn patterns from data and use those patterns to classify, estimate, recommend, or predict. A model that prioritizes transactions by fraud likelihood is a familiar example.

Deep learning is a subset of machine learning built on multilayer neural networks. It has driven major advances in vision, speech, and language. A generalist auditor does not need to understand the mathematics of network architectures. The important control implication is that, as behavior depends more on learned patterns, reviewing programmed rules becomes less informative and questions about data, validation, performance, and monitoring become more important.

A practical taxonomy looks like this:

Term	Plain-language meaning for audit	What changes in the audit question?
Rules-based automation	Executes explicitly defined logic. It may not be AI.	Are logic, configuration, access, and change management sound?
Machine learning	Learns patterns from data to estimate, classify, or recommend.	Are the data and model performance suitable for the intended use?
Deep learning	Uses complex neural networks to learn representations and patterns.	Is behavior understood and validated to a level appropriate for the risk?
Generative AI	Produces new content such as text, images, audio, or code.	How are variability, inaccurate content, and data use controlled?
RAG	Retrieves external or internal sources before generating an answer.	Are sources complete, current, authorized, and retrieved effectively?
Agent or agentic workflow	Can select steps and use tools to pursue an objective.	What can it do, with which permissions, and where is human approval required?

The critical shift is from predicting to generating

One useful way to organize the landscape is to separate predictive AI from generative AI. NIST's 2025 taxonomy uses these two broad classes as part of its security analysis of AI systems.

Predictive AI commonly answers questions such as: “Which transaction looks anomalous?”, “Which customer is more likely to default?”, or “Which category does this request belong to?” The output may be a score, a class, or a probability. Familiar risk themes include data quality and representativeness, bias, overfitting, insufficient performance, model drift, and use outside the context in which the model was validated.

Generative AI (GenAI) changes the nature of the output. NIST describes generative AI as a class of models that produces synthetic content derived from learned patterns. In practice, that can include text, images, audio, video, and code. Large language models (LLMs) are generative models focused on language and can produce plausible responses based on the context they receive.

That difference matters because fluent language is not the same thing as verified information. Generation is probabilistic: small changes in instructions, context, or configuration can produce different outputs. This introduces risk patterns that were less central in traditional automation, including fabricated or unsupported content, prompt sensitivity, information disclosure, inconsistent outputs, and user overreliance. The NIST AI RMF Generative AI Profile exists because generative systems introduce risk considerations that merit additional treatment beyond a general AI risk framework.

RAG and agents are not simply “more advanced models”

A second common confusion is to treat RAG and agents as if they were model categories parallel to machine learning. They usually describe how a system is built around one or more models.

Retrieval-augmented generation (RAG) connects a user question to a selected set of sources — for example, policies, contracts, procedures, or technical manuals — retrieves relevant passages, and adds them to the context provided to the model. The appeal for audit is obvious: an assistant can answer using approved organizational material rather than relying only on information absorbed during model training.

But RAG does not eliminate risk. It moves part of the control problem into retrieval. A system may cite an obsolete policy, miss the most relevant document, retrieve a passage out of context, expose information to a user without the right permissions, or produce an answer that looks grounded even though the source does not support the conclusion. The auditor therefore needs to ask not only “Which model is used?” but also “Which corpus does it search, how is it updated, how are permissions enforced, and how is retrieval quality tested?”

AI agents add another layer. A copilot may recommend an action; an agent may have tools that let it execute one. If the system can query a database, create a ticket, send a message, or update a record, control can no longer focus only on response quality. Permissions, action limits, logging, segregation of duties, approval gates, stopping conditions, and recovery from errors become part of the assurance surface.

Risk changes again when a system moves from producing information to producing actions.

One business process can contain several different technologies

Consider an accounts-payable process. An organization could use:

rules to block invoices without purchase orders;
a machine-learning model to assign an anomaly score;
an LLM to draft an explanation for why an invoice appears unusual;
RAG to retrieve the relevant procurement policy and surface the supporting section;
an agent to request evidence from the process owner and open a review case automatically.

These are not five levels on a single scale of “intelligence.” They are different capabilities with different control needs. The rule engine calls for configuration traceability and change management. The predictive model calls for evidence on data, validation, metrics, and monitoring. The LLM requires output-quality testing and appropriate-use controls. RAG adds source governance and access controls. The agent adds authority and action governance.

This is one reason the NIST AI Risk Management Framework frames risk management across the design, development, deployment, and use of AI systems rather than treating “the model” as the entire object under review.

Four questions clarify most use cases before detailed testing begins

In a planning meeting, four questions can quickly sharpen the audit scope:

Is the behavior defined by rules or learned from data? If it learns, auditors need to understand training or reference data, validation, and performance monitoring.
Does the system predict or generate? A risk score and an LLM-written narrative require different testing strategies.
Does the answer depend on information retrieved at runtime? If RAG or search is involved, source quality, freshness, and permissions become part of the control environment.
Does the system only recommend, or can it act? As operational autonomy increases, authority boundaries, approvals, and action logs become more important.

These questions do not replace a risk assessment. They make it better. Two applications using the same underlying model can have radically different risk profiles when one drafts internal text and the other makes or executes decisions affecting customers, payments, or access to resources.

Better taxonomy leads to better audit scope

For non-technical auditors, the value of this taxonomy is practical: it enables better questions without pretending to be a model engineer. An auditor can assess inventory, ownership, intended use, data, validation, access, monitoring, human oversight, and third-party governance, while also recognizing when specialist support is needed for statistical validation, architecture review, advanced cybersecurity, or adversarial robustness testing.

Technology names will keep changing, and vendor labels will change even faster. A more durable mental model is to ask: Are there rules? Does it learn from data? Does it generate content? Does it retrieve information? Does it use tools? Can it act?

Understanding that sequence does not turn an auditor into a data scientist. It turns an auditor into someone who can identify which evidence matters and where control can fail.