ISO 42001 internal auditor training: audit how your organisation governs its AI

Opens with a self-check on your knowledge of AI governance and the AI tools you use at work. Presents four real cases and the question each gives an auditor: the Dutch childcare benefits system that used nationality as a risk factor, with the government resigning in January 2021; Google's Bard giving a wrong answer in a promotional demonstration; Zillow's home price forecasts drifting from reality; and a 2025 Deloitte report for an Australian government department with fabricated content, after a generative AI tool was used. Draws four lessons on impact, release, operation and oversight. Introduces Atlas Assist, an AI customer-service software company in New York whose platform answers clients' customers, routes tickets and drafts replies. Ends with the twenty-six modules in four parts, the exam and a recap.

What you will be able to do

• Explain what real AI failures teach an internal auditor
• Ask the four audit questions on impact, release, operation and oversight
• Outline how the course audits Atlas Assist across four parts

Why it matters

Audit the AI in use, not only the paperwork; real failures show what an AI management system audit is there to find.

Practice: Practice: Welcome: why AI internal audit matters · 3 questions

Starts at Atlas Assist in New York, where an auditor asks for the AI risk assessment and is shown a model card and a privacy impact assessment, neither of which is the assessment clause 6.1.2 describes. Explains the structure: the harmonized clauses 4 to 10, two normative and two informative annexes, and 38 controls in nine areas. Covers the terms an auditor uses every day: risk assessment and impact assessment, linked but different, the Statement of Applicability, data quality, and controls that must work, with five shown in practice. Then covers the roles an organisation can have, such as AI providers, producers, customers, partners, subjects and authorities, with Atlas Assist as a provider and producer of its platform, a customer of its large language model and a processor of client data. Ends with a recap: the role decides what you audit.

What you will be able to do

• Describe the structure of ISO/IEC 42001 and its annexes
• Tell an AI risk assessment apart from an AI impact assessment
• Identify the organisation's AI roles for each system

Why it matters

Read the verb and ask the role; knowing the structure stops a model card being accepted as a risk assessment.

Practice: Practice: The standard through an auditor's eyes · 3 questions

Opens with last year's internal audit at Atlas Assist, where the head of data science audited his own team's model development process with no findings, two months before a client bank complained that Spanish-language complaints were routed to the slowest queue. Explains clause 9.2: audits at planned intervals, a programme that follows importance and past results, and objectives, criteria and scope for each audit. Covers the chain every finding rests on, criteria, evidence, finding and conclusion, shown on one control, human review of drafted replies, where the event log shows drafts sent within three seconds with no edits, and the same visit to data science written two ways. Then covers types of audit, including a client bank's second-party audit, and seven principles, with a small fintech in Mumbai using a second person to check its auditor. Ends with a recap.

What you will be able to do

• Explain what clause 9.2 requires of internal audit
• Write a finding from criteria, evidence and conclusion
• Apply the principles of auditing, including independence

Why it matters

No criteria and no evidence means no finding; nobody audits their own work, as the routing model case shows.

Practice: Practice: Clause 9.2 and the principles of auditing · 3 questions

Starts with a client airline wanting Atlas Assist's chatbot to approve small refunds on its own, which sales has already agreed, while the AI governance lead's records describe a chatbot that only answers questions. Explains how to audit external and internal issues that are specific to AI, shaped by role and jurisdiction and reviewed when they change, such as the whole platform depending on one language model provider that raises prices in January, and a clear decision on whether climate change is relevant. Covers the intended purpose: one answer for each AI system, used by every team that sells, builds or supports it, and how a change should travel through the system. Then covers roles determined system by system, since they decide which requirements and controls apply, with a point many auditors miss. Ends with a recap.

What you will be able to do

• Audit the AI-specific issues and the climate change decision
• Check that each AI system has one intended purpose used by all teams
• Determine the organisation's role for each AI system

Why it matters

Ask what it is for and who you are to it; two teams with two purposes for one system leave risks nobody planned for.

Practice: Practice: Context, purpose and roles · 3 questions

Opens at Atlas Assist, where the scope statement names only the chat and e-mail platform, the new call-summary feature is out of scope because it launched later, and two client contracts include call summaries with requirements such as telling customers when a reply was drafted by AI. Explains clause 4.2: who the interested parties are, what they require, and a decision on which requirements the system addresses, with examples at Atlas Assist. Covers how to test whether the requirements register is complete by sampling from four places and looking for each item, and why requirements must travel somewhere. Then covers clause 4.3, a documented scope with boundaries and applicability that considers the issues and requirements, and clause 4.4, the system's processes and their interactions, with no missing handovers. Ends with putting the scope next to the inventory, and a recap.

What you will be able to do

• Test the interested party requirements register for completeness
• Compare the scope with the inventory of AI systems
• Check the AI management system processes for missing handovers

Why it matters

Put the scope next to the inventory; an AI feature left out of scope still carries contractual and legal duties.

Practice: Practice: Interested parties, scope and the system · 3 questions

Starts in the chief executive's office at Atlas Assist, where the AI policy signed two years ago is framed on the wall, the chief executive calls AI the technology team's job, and the head of data science's request for model monitoring is shown in an e-mail. Explains clause 5.1: eight actions for top management, from a compatible policy and objectives to supporting other leaders, audited through decisions such as a residual risk accepted in writing by a named manager, with a logistics company in Singapore whose board delays a launch until testing is funded. Covers clause 5.2: an AI policy that is appropriate, frames objectives, includes two commitments, is documented, linked to other policies and communicated, with the three A.2 controls. Then covers clause 5.3: roles assigned and communicated, with someone ensuring conformity and someone reporting performance. Ends with a finding auditors often miss, and a recap.

What you will be able to do

• Audit top management commitment through decisions
• Check the AI policy against clause 5.2 and the A.2 controls
• Verify that AI roles and authorities are assigned and communicated

Why it matters

Follow the decisions, not the signatures; a policy on the wall means little if requests for monitoring go unfunded.

Practice: Practice: Leadership, AI policy and roles · 3 questions

Opens in the AI governance lead's office, where Atlas Assist copied its AI risk matrix from its information security system, scoring impact in dollars and downtime, so the risk of the routing model treating Spanish-speaking customers worse was rated low. Explains how the issues and requirements of clauses 4.1 and 4.2 should reappear as risks and opportunities, by domain, intended use and context, testing this by taking three issues and two requirements into the risk register. Covers AI risk criteria: established and maintained, fit for four jobs, with individuals and societies on the scales, and how risk appetite links to the AI policy as Annex B describes. Then covers planned actions, integrated into processes, such as a review step built into the platform's workflow, and checked for effectiveness, with records retained. Ends with how to audit the criteria and a recap.

What you will be able to do

• Trace issues and requirements into the AI risk register
• Check that AI risk criteria include harm to individuals and societies
• Verify that actions are integrated into processes and evaluated

Why it matters

Criteria decide what the assessment can see; a matrix scored only in money cannot see unfair treatment of customers.

Practice: Practice: AI risk criteria and planning · 3 questions

Starts with two people at Atlas Assist scoring the same risk, the chatbot giving confident wrong answers, one low and one high, because one reads likely as once a year and the other as every day, somewhere. Explains auditing the design of the process: aligned with policy and objectives and producing consistent, valid and comparable results, tested by recalculating one line of the register using the written criteria. Covers the analysis: consequences to the organisation, individuals and societies, shown for the wrong-answers risk, a likelihood with a basis, including for a new voice feature with no production data, and a level, with Annex C risk sources as prompts, not a checklist. Then covers evaluation against the criteria and prioritisation, with the work log showing a low risk treated first because it was easy, and the link to impact assessment findings. Ends with a recap.

What you will be able to do

• Recalculate a risk score using the written criteria
• Check consequences cover the organisation, individuals and societies
• Verify that treatment order follows the order of risk

Why it matters

Recalculate one line and count the levels; inconsistent scoring makes the whole risk register unreliable.

Practice: Practice: AI risk assessment · 3 questions

Opens with Atlas Assist's Statement of Applicability marking all thirty-eight Annex A controls as included with no justification column, while its second-highest risk, wrong answers about refunds, is treated by agent review of every reply about money, a control the Statement omits. Explains treatment: options chosen from the assessment and controls determined from the risks, then compared with Annex A so no necessary control is omitted, and the idea auditors most often get backwards. Covers the Statement of Applicability: the necessary controls, including the organisation's own, each with a justification for inclusion or exclusion, which can apply to objectives or specific systems, and a treatment plan approved by designated management, with a justified exclusion at a media company in Paris. Then follows the trail from risk to plan to control to evidence, seeing the control in place in the platform's workflow. Ends with a recap.

What you will be able to do

• Check that controls are determined from the risks, then compared with Annex A
• Audit the Statement of Applicability for justifications
• Trace a risk to its control and the evidence it works

Why it matters

Every control needs a risk and every risk a control; a Statement that lists everything justifies nothing.

Practice: Practice: AI risk treatment and the Statement · 3 questions

Starts with Atlas Assist's chatbot impact assessment, done at launch two years ago for text chat with retail customers, untouched since a voice channel was added and an electricity utility with many elderly customers and people in financial hardship was signed. Explains the process: consequences for individuals, groups and societies from deployment, intended use and foreseeable misuse in the real context, including wider effects such as energy use, access to help and agents' jobs and skills. Covers timing: assessments at planned intervals and whenever a significant change is proposed, under clause 8.4, tested by comparing the change log with the assessment dates. Then covers results documented, retained for a defined period and considered in the AI risk assessment, with the four A.5 controls and three examples at Atlas Assist. Ends with a finding auditors often miss and a recap.

What you will be able to do

• Audit an impact assessment for individuals, groups and societies
• Compare the change log with impact assessment dates
• Check that impact results feed the AI risk assessment

Why it matters

Find the people the design team never met; an outdated impact assessment misses vulnerable customers on new channels.

Practice: Practice: AI system impact assessment · 3 questions

Opens with Atlas Assist's only AI objective, we will use AI responsibly, with no measure, no single owner and no date, while data science tracks a wrong-answer rate monthly against a target nobody wrote down. Explains clause 6.2: AI objectives at relevant functions and levels, consistent with the AI policy, measurable if practicable, taking requirements into account, monitored, communicated, updated and documented, shown as a set of objectives and the cascade between levels. Covers plans that answer what, resources, who, when and how results are evaluated, following a language objective through a year: set in January and updated when the voice channel arrives in March. Then covers clause 6.3, changes to the AI management system carried out in a planned manner, shown by migrating the risk register from an outgrown spreadsheet and comparing every line. Ends with a recap.

What you will be able to do

• Check that AI objectives are measurable, owned and documented
• Audit plans for what, resources, who, when and evaluation
• Verify that changes to the system are planned and checked

Why it matters

An objective nobody can check is a slogan; measurable objectives turn the AI policy into results management can review.

Practice: Practice: AI objectives and planning of changes · 3 questions

Starts in a client's support team using Atlas Assist, where new agents learn the product in a two-day course with nothing on how AI drafts go wrong, and one agent did not know she could reject a draft. Explains clause 7.1: resources determined and actually provided, comparing what was asked for with what was given. Covers clause 7.2: competence determined for every role whose work affects AI performance, including human oversight, with actions evaluated for effect and evidence kept, shown in Atlas Assist's competence table and an insurer in London whose claims handlers can override an AI triage tool. Then covers clause 7.3 awareness, tested with three open questions to a support agent, and clause 7.4 communication of what, when, with whom and how, with a retail chain in Dubai whose marketing team does not know the policy. Ends with a recap.

What you will be able to do

• Compare the resources requested with those provided
• Audit competence for roles that oversee AI output
• Test awareness with open questions to the people doing the work

Why it matters

Human oversight is only as good as the human; agents who trust every AI draft cannot stop a wrong refund.

Practice: Practice: Resources, competence, awareness, communication · 3 questions

Opens at Atlas Assist, where a product manager edited one client's chatbot system prompt directly in production on a Friday afternoon, with no version number, review or record of the old text. Explains what must exist: the documented information the standard requires and what the organisation decides is necessary, in any format, including release checklists and chatbot instructions, and where it hides, from system prompts and model configuration to thresholds and release criteria. Covers creating and updating: identified, in the right format, reviewed and approved, with the new route for a prompt change. Then covers control: availability, protection, access, version control and retention, which needs special care because some AI records are huge and some sensitive, including documents from outside, with a car-parts maker in Tokyo whose vision AI threshold file has no date, author or approval. Ends with a recap.

What you will be able to do

• Identify AI documents that must be controlled, including system prompts
• Check version control, review and approval of AI instructions
• Audit retention and access for large or sensitive AI records

Why it matters

If it tells the AI how to behave, control it; an unrecorded prompt edit changes a live system with no way back.

Practice: Practice: Documented information · 3 questions

Starts with Atlas Assist's strong release procedure, which every new model version passes, while the routing model retrains itself weekly through an automated pipeline that never goes through it, until a weekly version starts misrouting tickets. Explains clause 8.1: criteria for each process, operational controls in place and their effectiveness monitored, with corrective action considered, and evidence such as the human review log. Covers controlling planned changes, reviewing and mitigating unintended changes, shown in one handled well at Atlas Assist, and controlling outside providers, such as testing a new language model version before switching. Then covers clauses 8.2 and 8.3: AI risk assessments repeated at planned intervals and on significant change, and treatments implemented, verified, revalidated and updated, followed from implementation in June to a sample check in September, with a logistics company in Singapore retraining monthly. Ends with comparing reassessment dates with the change log, and a recap.

What you will be able to do

• Check that automated retraining is covered by operational controls
• Audit control of planned, unintended and supplier changes
• Compare risk reassessment dates with the change log

Why it matters

AI systems change even when nobody changes them; automated retraining outside release control can break a tested model.

Practice: Practice: Operation: control, risk and treatment · 3 questions

Opens with Atlas Assist's live dashboard of forty-seven measures for the chatbot and routing model, which nobody can say was reviewed or acted on, and management review minutes with no audit results, nonconformity trends or status of last year's actions. Explains clause 9.1: deciding what to monitor and measure, with valid methods and timing, for both the AI systems and the management system, with four examples and why results must be split by group for AI. Shows one month at Atlas Assist, from hourly platform monitoring to a monthly sample evaluated in October with a decision for the voice channel, and a food-delivery platform in Chicago with an automated dispatch model. Then covers clause 9.3: review by top management at planned intervals, with every required input and decisions on record, as at a media company in Paris adding a second editor check. Ends with a recap.

What you will be able to do

• Check that monitoring results are evaluated and lead to decisions
• Audit whether AI performance results are split by group where it matters
• Verify that management review covers every required input

Why it matters

Measuring is not managing until someone decides; a dashboard nobody evaluates hides drift and unfair outcomes.

Practice: Practice: Monitoring and management review · 3 questions

Starts with a client airline complaint in May that Atlas Assist's chatbot promised compensation the airline does not offer, fixed within an hour for that client and closed, followed in June by a utility client complaining of the same kind of promise. Explains clause 10.2: reacting by controlling and correcting the nonconformity and dealing with consequences, then reviewing it, determining causes, looking for similar ones, acting, reviewing effectiveness and changing the system if necessary. Shows the worked finding from tickets 2207 and 2291, where a correction was called corrective action, and the corrective action Atlas Assist finally took across three cases, such as a new risk in the register or a new control in the Statement of Applicability. Then covers clause 10.1 continual improvement and five sources to sample, including suppliers. Ends with a recap.

What you will be able to do

• Tell a correction apart from a corrective action
• Audit cause analysis and the check for similar nonconformities
• Sample five sources of nonconformities, including suppliers

Why it matters

A correction fixes today and corrective action fixes tomorrow; without it, the same AI failure moves to the next client.

Practice: Practice: Improvement and corrective action · 3 questions

Opens with a junior engineer at Atlas Assist who noticed the gap in Spanish test data months before the routing complaint, raised it in a team chat, and was told fairness was not her area, because there was no way to report a concern. Explains the map of ten controls in three areas of Annex A, starting with A.2.2 on the AI policy: documented, aligned with other policies, and reviewed at planned intervals and when things change. Covers internal organisation: roles defined to the level people need, and a working process to report concerns, with a worked nonconformity on A.2.4 in four parts and a contractor at a bank in Frankfurt using an anonymous channel. Then covers resources for AI systems: data, tooling, computing and people documented for each system, audited on the routing model and at a university in Sydney buying an essay-flagging tool. Ends with a recap.

What you will be able to do

• Audit the AI policy and its review against Annex A
• Test the process for reporting concerns about AI systems
• Check that resources are documented for each AI system

Why it matters

Test the channel, not the poster; an engineer who cannot report a fairness concern is a control that does not exist.

Practice: Practice: Annex A: policies, organization, resources · 3 questions

Starts with the release records of Atlas Assist's voice channel, whose speech recognition was tested on two thousand recordings made by New York staff, then released to callers in many countries and accents, many of whom were misheard. Explains six life cycle controls, starting with A.6.1.2, objectives for responsible development, built into every stage, and processes that define how design and development are done. Covers requirements and specification, and documenting the design choices behind the system, with a food-delivery platform in Chicago recording its model type, training approach and AI-specific security threats. Then covers verification and validation with representative test data and criteria set in advance, and a deployment plan with requirements met before release, with a car-parts maker in Tokyo using vision AI to inspect brake parts. Ends with what you usually find, a worked nonconformity and a recap.

What you will be able to do

• Audit objectives for responsible AI development across the life cycle
• Check that test data represent the people and conditions in use
• Verify that release criteria are set and met before deployment

Why it matters

Criteria first, test data like reality and approval before release; untested accents become complaints within a month.

Practice: Practice: Life cycle, part 1: build and release · 3 questions

Opens with a client bank's complaint about wrong loan payment information given three weeks earlier, which nobody can investigate because Atlas Assist keeps event logs for seven days to save storage. Explains A.6.2.6 on AI system operation and monitoring: repairs, updates and support, with drift and unexpected uses watched. Covers technical documentation for each relevant category of interested party, and event logs that can rebuild what happened, for as long as needed. Then covers the five data controls: data management processes, acquisition with clear rights, data quality against requirements, provenance, and preparation you can explain, shown meeting on one dataset, the labelled tickets behind the routing model, with a worked nonconformity on A.7.4. Includes a fintech in Mumbai buying merchant data from a broker for its fraud model. Ends with a recap.

What you will be able to do

• Check that event logs can rebuild what happened, for long enough
• Audit technical documentation for each category of interested party
• Audit data acquisition, quality, provenance and preparation

Why it matters

Every output stands on its data and its logs; seven-day logs make a three-week-old complaint impossible to investigate.

Practice: Practice: Life cycle, part 2, and data · 3 questions

Starts with Atlas Assist's rule that every customer is told in the first message they are talking to an AI, and a retail client whose chatbot, given the name Emma, never says she is an AI because sales agreed to remove the notice. Explains seven controls in two areas, starting with A.8.2, system documentation and information for users, including that they are dealing with AI and a way for anyone to report adverse impacts. Covers a plan for communicating incidents and a documented list of what is owed to authorities and others, reported completely. Then covers the use of AI systems: processes and objectives for responsible use, shown for the AI tools staff use every day at Atlas Assist, meaningful human oversight, and use according to the intended uses, with an insurer in London and its AI triage tool. Ends with a recap.

What you will be able to do

• Test whether users are told they are dealing with AI
• Audit incident communication and obligations to authorities
• Check that AI is used according to its intended uses with real oversight

Why it matters

Tell people the truth and use AI as intended; a rule on paper means nothing if a client can switch the AI notice off.

Practice: Practice: Information for parties, and use of AI · 3 questions

Opens in procurement at Atlas Assist, where the labelling vendor's contract covers quality and confidentiality, but an invoice reveals that half the labelling work, including customer conversations, went to a subcontractor Atlas Assist was never told about. Explains A.10.2, allocating responsibilities across the life cycle between the organisation, its suppliers, partners and customers, written into contracts, with an example allocation for Atlas Assist's platform. Covers A.10.3 on suppliers chosen, required, monitored and corrected, following the language model provider through it and comparing two ways of writing a checklist line. Then covers customers given what they need to treat their side of the risk, such as telling client banks in writing that the chatbot is not designed to give loan or investment advice. Ends with the evidence to request from AI governance, engineering and other functions, starting from the Statement of Applicability, and a recap.

What you will be able to do

• Check that AI responsibilities are allocated in contracts
• Audit supplier selection, requirements, monitoring and correction
• List the evidence to request from each function

Why it matters

Using a supplier never moves the accountability; an unknown subcontractor can hold your customers' conversations.

Practice: Practice: Third parties, customers and the evidence · 3 questions

Starts with last year's one-line internal audit plan at Atlas Assist, worked through in the order of the manual, so nobody reached the chatbot, its release records or event logs. Explains a programme that considers the importance of processes and the results of previous audits, with the most effort where AI risk is highest, shown as a grid of areas and months. Covers how events change the programme: the model provider changes the model in April, wrong-answer complaints rise in May, and a short audit of supplier change control is added in July. Then covers defining objectives, scope and criteria for each audit with clauses and controls named by number and title, such as audit two on the chatbot's controls for all clients with records from April to June, a plan that puts the riskiest AI system first, and checklists that ask for evidence. Ends with a recap.

What you will be able to do

• Build a risk-based audit programme for AI systems
• Define audit objectives, scope and criteria by clause and control
• Write a checklist that asks for evidence

Why it matters

Plan from risk, then audit to the plan; a document-order plan runs out of time before the AI systems themselves.

Practice: Practice: Planning the audit programme, plan, checklist · 3 questions

Opens with an auditor arriving at Atlas Assist with no opening meeting and typing tricky questions into a client's live chatbot from a borrowed account, until the client's monitoring flags the conversations as an attack. Explains the opening meeting: agreeing the plan, introducing the team and their roles, and confirming the audit can run, including access, shown as a ten-minute meeting in four parts for the chatbot audit, and a two-minute version with the marketing lead. Covers working on site: security rules on badges, devices and screens, keeping hands off live systems, and asking permission for screenshots that can carry customers' names and complaints. Then covers remote methods, such as the trust lead opening the live log on a shared screen and searching for conversations the auditor names, and spotting the odd, such as test runs that all finish in the same number of seconds. Ends with a recap.

What you will be able to do

• Run an opening meeting that confirms plan, roles and access
• Follow security rules and keep hands off live AI systems
• Use remote methods to see the real system, not a prepared file

Why it matters

Open well, observe, and people talk; an auditor who tests a live client chatbot can trigger a security incident.

Practice: Practice: Conducting the audit, I opening, site, people · 3 questions

Begins with a trail at Atlas Assist: a client reports the chatbot told a customer about a refund rule the client never had, and the release's test results are signed off with every test green, so the auditor asks the engineer to show the test set itself. Explains how only verifiable information becomes audit evidence, checked as complete, correct, consistent and current, including verifying the source behind any dashboard. Covers sampling fairly, sizing the sample to the risk and recording exactly what was looked at, with identifiers such as the release number, log entry, ticket, test run, model version and dataset version. Then covers interviews across four roles, open questions to explore and closed ones to confirm, and following one AI system end to end through the clauses and controls, asking questions such as whether performance is monitored in use. Ends with a recap.

What you will be able to do

• Verify information as complete, correct, consistent and current
• Record samples with release, model and dataset identifiers
• Follow one AI system end to end through clauses and controls

Why it matters

Information becomes evidence when it is verified; a green test report means nothing until you see the test set.

Practice: Practice: Conducting the audit, II evidence and sampling · 3 questions

Begins at the moment you finish auditing an area: share findings there and then, review each nonconformity with the auditee before the closing meeting under clause 6.4.8, and let them show further evidence. Explains grading as yours to define and communicate, shown at Atlas Assist, and opportunities for improvement from an insurance company in Sydney that uses AI to sort claims, where drift reports are always reviewed a week after month end. Covers writing every statement in four parts, criteria, evidence, the statement and the grade, with precise release numbers, log entries, dates, roles and quantities, such as a log store with no entries for part of August during a migration, and four nonconformities that will not stand. Then covers a closing meeting with no surprises, a report stating that audits are a sampling exercise, reporting to relevant managers, and verifying that each action worked. Ends with a recap.

What you will be able to do

• Write a nonconformity in four parts with precise evidence
• Tell a nonconformity apart from an opportunity for improvement
• Verify that corrective actions worked before closing them

Why it matters

An audit ends when the actions work; precise findings are the ones management can check and fix.

Practice: Practice: Findings, reports, and follow-up · 3 questions

Walks through an effective internal audit step by step. Step one is to start from the standard: identify every clause and every Annex A control in the Statement of Applicability that applies to the area, build the checklist from them, then add the area's significant AI risks and, only then, the procedure. Follows a practice audit at Atlas Assist, showing what the auditor heard, what she checked and what she found, such as eight replies traced and all conforming, and eight training records sampled with two agents hired in August lacking the AI use training. Covers the ways a good finding dies, such as auditing only the procedure, taking answers on trust and writing opinions with no criteria, and a quick check. Ends with a three-line recap of the course and the final exam.

What you will be able to do

• Build an audit checklist from the standard and the Statement of Applicability
• Conduct a practice audit that follows one AI system end to end
• Avoid the common ways good audit findings fail

Why it matters

Audit so that AI is developed and used responsibly; the practice audit shows the whole method working on one system.

Practice: Practice: A practice audit, and the exam · 3 questions