AI Governance in Practice: Auditing Models, Agents and Vendors
UIT, UIB, UIC, UID Cross-institute lecture
Series Cross-Institute Series
Duration 25 minutes
Delivering institutes: UIT (Institute of Technology); UIB (Institute of Business); UIC (Institute of Communication); UID (Institute of Design)
UNOP Sound (University 365 Neuroscience Oriented Pedagogy)
Take five minutes to prepare your brain. Play the isochronous tone track (40Hz gamma frequency) with your eyes closed. Gamma-frequency tones before a learning session raise attention and make the material easier to absorb.
[Audio player: UNOP Pre-Lecture Isochrone (40Hz, 5 minutes)]
In this Lecture
AI Governance in Practice: Auditing Models, Agents and Vendors
Governance Is Not a Policy PDF
Most organisations have an AI policy. Far fewer can answer three practical questions about a live system: what exactly is running, what evidence proves it behaves as intended, and who signed the decision to let it act. The policy describes intent. The audit produces evidence. The gap between the two is where incidents live.
AI governance becomes real when it is operational: an inventory with owners and risk tiers, an evidence pack per system, a release gate that blocks changes without evidence, an incident path that works, and a cadence that keeps the evidence current. That is an audit function, and it applies to models you rent, agents that act, and vendors that sit between you and the model.
This lecture is the practical version. It covers what an audit examines, the evidence stack, how to audit models you did not train, how to audit agents and vendors, how to grade findings and drive remediation, how the major frameworks map to evidence, and how to build a usable audit pack in thirty days. It is written for the people who will be asked, by a board, a regulator or a customer, to prove that the system is under control.
AI Governance in Practice: Auditing Models, Agents and Vendors
What an AI Audit Examines
An AI audit is not a code review and not a vendor questionnaire. It examines the system in use, against a defined standard, with evidence.
Scope and inventory. What systems exist, what they do, who owns them, what data they touch, what decisions they influence, and how they are classified. An inventory that lists only the systems IT knows about is already incomplete; shadow AI is part of the audit.
Design and intent. The documented purpose, the intended users, the boundaries, the human oversight, the prohibited uses. The audit checks whether the design matches the claim.
Data. The sources, the permissions, the retention, the quality controls, the provenance. For models you did not train, the data question becomes a question about retrieval and fine-tuning data you do control.
Model and system evidence. Evaluation results, known limitations, version control, change history, monitoring, incident logs. The evidence must be yours, not a vendor benchmark.
Human oversight. Who reviews, what they see, what authority they have, how they are trained, how their decisions are recorded. Oversight that exists on paper but not in the workflow is a finding.
Outcomes and complaints. Errors, incidents, near misses, user complaints, corrections, appeals. An audit that only looks at design and ignores outcomes is a documentation exercise.
Governance. Ownership, accountability, the release gate, the risk register, the training record, the third-party contracts. The operating system around the system.
The audit's output is a set of findings with evidence, severity, an owner and a date. Anything else is a report.
AI Governance in Practice: Auditing Models, Agents and Vendors
The Evidence Stack
Evidence accumulates in layers. Build the stack once, and every audit, customer questionnaire and regulatory request becomes a retrieval exercise instead of a project.
Layer 1: Inventory. A row per system: name, purpose, owner, business unit, model and vendor, risk tier, data classes, users, status. Keep it current through procurement and change management, not through an annual survey.
Layer 2: Model evidence. The model and version, the provider, the evaluation results on your own task, the known limitations, the failure modes, the fallback. For rented models, this is your evidence, not the provider's marketing.
Layer 3: System evidence. The prompts and their versions, the retrieval sources and permissions, the data flows, the logs, the human review points, the release gate decisions. This is where most audits find the real gaps.
Layer 4: Agent evidence. The tools the agent can call, the permissions on each, the actions taken, the confirmations, the side effects, the stop and rollback. Agents need a different evidence set because they change the world as well as the text.
Layer 5: Vendor evidence. The contract, the data use and training terms, the retention, the subprocessors, the security certifications, the change notice, the exit plan, the audit rights. A vendor that will not answer these questions is a risk, not a partner.
The stack is also a communication tool. When a regulator asks how you manage AI risk, you do not describe a framework. You show the inventory, one evidence pack, the gate decision and the last audit's findings. Evidence beats narrative.
AI Governance in Practice: Auditing Models, Agents and Vendors
Auditing Models You Did Not Train
You cannot audit the training of a rented frontier model. You can audit the relationship and the use.
Provenance and version. Record which model, which version, which provider, and when it changed. Pin versions where the provider allows it. For each change, require notice and run your evaluation before switching.
Your evaluation, not the benchmark. Audit the evidence that the model performs on your task: the golden set, the rubric, the pass rate, the severe errors, the slices that fail. A provider benchmark is context; your evaluation is evidence.
Known limitations. Document the failure modes you have observed and the ones the provider discloses. State the mitigations: retrieval constraints, human review, output validation, refusal rules. An undocumented limitation is a latent incident.
Data handling. Confirm whether your inputs and outputs train the provider's models, in every tier in use, including free and trial tiers used by staff. Confirm retention, deletion and location. Get it in writing, and test the deletion path.
Concentration and dependency. Record the dependency on one provider, the fallback, the exit cost, and the contractual notice. A model you cannot replace in an emergency is an operational risk.
Monitoring. Check that you can detect drift, quality degradation and cost anomalies without the vendor telling you. Model upgrades are the most common cause of silent quality change.
The audit conclusion is not "the model is safe". It is "the model is suitable for this use, with these limitations, these controls and this evidence". That is a defensible position.
AI Governance in Practice: Auditing Models, Agents and Vendors
Auditing Agents
An agent audit asks a different question: what the system does, as well as what the model says.
Tool inventory and permissions. List every tool the agent can call, the permission scope, the data it can read or write, and whether the action is reversible. A tool with write access and no confirmation is a finding, regardless of the model's quality.
Action boundaries. The maximum consequence of one error: one email, one record, one payment up to a limit. Verify that the boundary is enforced in code, not in the prompt. Prompts are not controls.
Human oversight in practice. Sample real traces. Did the human see the plan, the evidence and the consequences before approval? Did they have time to review? Did they approve without reading? Oversight that is nominal is a finding.
Logging and reconstruction. Pick three transactions and reconstruct them end to end from logs: the input, the retrieved context, the model calls, the tool calls, the output, the approval. If reconstruction requires asking an engineer, the logging is insufficient.
Prompt injection and tool poisoning. Review the adversarial test set. Check that retrieved content is treated as untrusted, that tool results cannot expand permissions, and that the agent cannot be instructed to exfiltrate data by a document.
Stop and rollback. Verify the kill switch, the rollback of side effects where possible, and the incident path. Test the stop control as well as the documentation of it.
Change control. Any change to the prompt, the tools, the permissions or the model is a release. Verify that the gate covers agents, which are often changed through configuration rather than code.
The agent audit is closer to an operational audit than a model audit. That is the point: the risk has moved from the text to the action.
AI Governance in Practice: Auditing Models, Agents and Vendors
Auditing Vendors
A vendor audit protects you from risks you cannot see. It has four parts.
Contract and data. Data use, training, retention, deletion, location, subprocessors, breach notification, liability, indemnity. The clauses must match the actual product behaviour; test the settings the vendor describes.
Security. Certifications, penetration test summaries, access controls, encryption, incident history, vulnerability disclosure. Ask for the evidence behind the badge, and check the scope covers the service you use.
Model and change management. Which models, which versions, how changes are communicated, how deprecations are handled, whether you can pin versions, and what happens to your prompts and data when a model is retired.
Exit and portability. Export formats, data deletion, transition assistance, notice periods. The exit plan is the test of the relationship: a vendor that cannot describe the exit has not thought about your risk.
Concentration. If the vendor is the only path to a critical workflow, document the fallback. The fallback can be manual; it cannot be imaginary.
Score each vendor on a simple red, amber, green scale and record the evidence. The score is less important than the record: it shows what you checked, when, and what you accepted.
AI Governance in Practice: Auditing Models, Agents and Vendors
Findings, Severity and Remediation
An audit without severity is a list. Severity drives action.
Severity 1, critical. Unauthorised action, data exposure, a system operating without the required human oversight, a prohibited use. Response: same day, stop or restrict the system, notify the accountable executive, preserve evidence.
Severity 2, high. A high-stakes output with no review, a missing control on an irreversible action, a vendor processing data outside the agreed terms, an evaluation that has not run before a model change. Response: within five days, restrict or remediate, document the decision.
Severity 3, medium. Stale evaluations, incomplete logging, unclear ownership, documentation drift. Response: within thirty days, plan and assign.
Severity 4, low. Documentation gaps, cosmetic inconsistencies, training records missing for a small group. Response: within ninety days, backlog.
Every finding needs four fields: evidence, severity, owner, date. A finding without an owner is an observation. A finding without a date is a hope.
Track remediation in the same register as the risk. Report open findings by severity monthly to the accountable executive, and quarterly to the board. Close a finding only with evidence, not with an assertion.
AI Governance in Practice: Auditing Models, Agents and Vendors
Regulation Mapped to Evidence
Three frameworks dominate the conversation. You do not need to adopt all three; you need to map your evidence to the one your regulator, customer or board expects.
The EU AI Act. For high-risk systems, the Act expects risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness and cybersecurity. Provider and deployer duties differ, and the enforcement framework now separates them: the AI Office supervises general-purpose models, while national authorities supervise most other systems. If your system is high-risk, your evidence pack should map to those requirements article by article.
The NIST AI Risk Management Framework. The framework's four functions (govern, map, measure, manage) are a useful operating vocabulary. Its generative AI profile adds specific risks: confabulation, data privacy, information security, harmful content, environmental impact. Use it to structure the risk register and the audit questions.
ISO/IEC 42001. The management-system standard asks for policy, roles, risk assessment, operational controls, performance evaluation and improvement. It is the closest fit for an organisation that wants a certifiable system rather than a project.
Map once, in a table: framework requirement, your control, your evidence, your owner. The table is the single artefact that answers a regulator, a customer and an auditor without rebuilding the answer each time. Update it when the regulation changes, and date every version.
The trap to avoid is framework theatre: a policy mapped to a standard, with no evidence behind the controls. An auditor will ask for the evidence, not the mapping.
AI Governance in Practice: Auditing Models, Agents and Vendors
Building the Audit Pack in Thirty Days
Days 1 to 5: Inventory and scope. List every AI system, including shadow tools, with owner, purpose, vendor, model, data classes, users and risk tier. Pick the three highest-risk systems for the first evidence packs.
Days 6 to 12: Evidence collection. For each system, collect the model and version, the evaluation results, the prompts, the data flows, the permissions, the logs, the human review points and the release decisions. Mark every missing item as a finding.
Days 13 to 18: Agent and vendor review. For agents, list tools and permissions, sample ten traces, test the stop control. For vendors, collect the contract clauses, security evidence and exit plan for the top five.
Days 19 to 24: Findings and remediation. Grade every gap, assign an owner and a date, and agree the Severity 1 and 2 actions with the accountable executive. Do not wait for the full pack to fix a critical finding.
Days 25 to 30: Report and cadence. Write the audit report: scope, method, findings, evidence, decisions. Set the cadence: monthly access and incident review, quarterly evaluation and vendor check, annual full audit, event-driven reviews. Present to the board with the open findings and the decisions required.
The pack is not a one-off. It is the operating record of the governance system, and its value grows with each cycle.
AI Governance in Practice: Auditing Models, Agents and Vendors
The Governance Operating Model
Governance fails when it is nobody's job. The operating model names the roles, the decision rights and the cadence.
The accountable executive. One named person owns the AI risk appetite and signs the highest-tier decisions. The role cannot be delegated to a committee; the committee advises, the executive decides.
The AI governance lead. Runs the inventory, the evidence process, the audit cadence and the reporting. This is a operating role with authority to stop a release, not a communications role.
The system owner. Owns each system's purpose, evidence, performance and incidents. Every row in the inventory has a name.
Risk and compliance. Owns the framework mapping, the regulatory interpretation, the vendor due diligence and the incident notifications.
Security. Owns access, tool scoping, adversarial testing, logging integrity and the incident response for security events.
The AI review board. A monthly forum with the accountable executive, the governance lead, risk, security and the business owners. It reviews new high-risk systems, open Severity 1 and 2 findings, and changes to the risk appetite. It does not approve every prompt; it approves the system and the exceptions.
Decision rights are the part most organisations skip. Write them down: who can approve a new system, who can change a risk tier, who can approve a model switch, who can accept a residual risk, who can stop a system. A decision made by the wrong role is a finding even when the outcome is good.
AI Governance in Practice: Auditing Models, Agents and Vendors
Incident Response for AI
AI incidents have a different shape from security incidents. The system can produce a harmful output without an attacker, and the evidence may be a single wrong answer that was acted on.
Detection. Sources: user reports, output monitoring, evaluation regressions, vendor notices, external mentions, audit findings. Make the reporting route visible in the interface and known to the support team.
Containment. Switch the system to a safe mode, restrict the workflow, disable a tool, or stop the service. The kill switch must be usable by the business owner without engineering, and tested.
Assessment. What happened, to whom, how many cases, what data, what action was taken. Preserve the traces before any fix overwrites them.
Notification. Legal and compliance decide the obligations: affected users, customers, regulators, the board. For high-risk systems, the notification path should be written before the incident.
Remediation. Fix the cause, add the case to the evaluation set, update the controls, and re-run the gate. A fix without a test case is a hope.
Learning. A postmortem without blame, focused on the control that failed. Share the lesson across systems; the same failure usually exists elsewhere.
Run one tabletop exercise a year with the accountable executive. The exercise reveals the gaps in authority and contact paths before a real event does.
AI Governance in Practice: Auditing Models, Agents and Vendors
Third-Party and Supply Chain Evidence
The AI supply chain adds dependencies that traditional vendor management does not cover.
Model provenance. Which model, from which provider, trained on what (as far as disclosed), with which licence and use restrictions. Record the answers and the date. For open-weight models, record the licence and the provenance of the weights.
Subprocessors. The vendor's model provider, hosting provider, data processor and any annotation or support subcontractor. Your data flows through them. The list must be complete and contractually controlled.
Concentration. How many critical workflows depend on one provider, one model family, one cloud region. Document the fallback and the time to switch. A fallback that has never been tested is a plan, not a control.
Change notice. The vendor's obligation to tell you before a model change, a deprecation or a material security event. Without notice, your evaluation cannot run before the change reaches users.
Audit rights. The right to audit, or to receive an independent audit report, covering the service you use. Check the scope; a certification for a different service is not evidence for yours.
Exit. Data export, model portability (where it exists), prompt and log export, deletion, transition assistance and notice. Test the export once, before you need it.
Keep the vendor evidence in the same pack as the system evidence. The auditor will ask how the vendor's behaviour affects your system, and the answer should not require a separate project.
AI Governance in Practice: Auditing Models, Agents and Vendors
Metrics for the Board
Six metrics tell the board whether governance is working.
Coverage. The share of AI systems in the inventory with an owner, a risk tier and a current evidence pack. Coverage below 100 percent is the first finding.
Gate compliance. The share of production changes that passed the release gate. Any change outside the gate is a control failure.
Open findings by severity. The count and age of Severity 1 and 2 findings. An ageing Severity 2 is a leading indicator of an incident.
Incidents and near misses. The number, the severity, the time to contain, the time to remediate. Near misses are free lessons; report them.
Evaluation currency. The share of systems with an evaluation run in the last quarter, and the share of model changes that triggered an evaluation before release.
Vendor assurance. The share of critical vendors with current security evidence, contract clauses and a tested exit.
Report the trend as well as the point. A single month of good numbers after a bad quarter is noise; three months is a signal.
AI Governance in Practice: Auditing Models, Agents and Vendors
Common Audit Failures
Seven failures recur across organisations. Name them in the audit plan.
Inventory by survey. The list is compiled annually and misses shadow tools. Fix: procurement and SSO feeds, continuous.
Policy without evidence. The controls are described, not tested. Fix: sample the evidence for each control.
Nominal oversight. A human clicks approve without reading. Fix: sample traces and measure review time.
Prompt-based controls. A permission is enforced by instruction, not by code. Fix: enforce in the tool layer.
Vendor evidence from marketing. A certification badge with no scope. Fix: request the report and check the scope.
Findings without owners. A list of risks with no dates. Fix: four fields per finding, tracked monthly.
Audit as a project. The pack is built once and decays. Fix: a cadence with named owners and a board report.
Each failure has a cheap fix. The expensive version is discovering it after an incident, when the evidence is the first thing the regulator asks for.
AI Governance in Practice: Auditing Models, Agents and Vendors
A Worked Example: The Support Agent Audit
A customer support team deploys an agent that reads tickets, retrieves policy articles and drafts replies. A human sends them. After three months, the agent is allowed to issue refunds up to fifty euros without review.
The audit finds five things.
Finding 1, Severity 1: the refund tool is not bounded in code. The fifty-euro limit is written in the prompt. A prompt injection in a customer message can instruct the agent to ignore the limit. The tool itself accepts any amount. Fix: enforce the limit in the tool layer, require an approval token above it, and add the injection case to the adversarial set. Action: same day, refunds disabled until the fix.
Finding 2, Severity 2: retrieval ignores regional entitlements. The policy corpus is global, and the retriever does not filter by the customer's region. Agents have quoted an EU policy to a US customer. Fix: entitlement metadata on every chunk and a filter before the model. Action: five days.
Finding 3, Severity 2: no evaluation before the last model switch. The provider changed the model version, and the team switched because the latency improved. No golden set was run. Fix: pin the version, require a gate for any model change, and run the 200-case set. Action: five days.
Finding 4, Severity 3: oversight is nominal. Reviewers approve 94 percent of drafts in under four seconds. Fix: sample and measure review time, introduce a random deep-review queue, and report the review quality metric. Action: thirty days.
Finding 5, Severity 4: the vendor contract is silent on subprocessors. The model provider uses a subprocessor not listed in the contract. Fix: amend the contract and add the subprocessor to the register. Action: ninety days.
The audit report is four pages: scope, method, findings, decisions. The board sees three numbers: one Severity 1 closed, two Severity 2 in progress, coverage at 78 percent. The value is not the document. It is the refund limit now enforced in code and the model switch now gated.
That is the pattern: the audit finds the control that exists in the story but not in the system. Fix the system, keep the evidence.
AI Governance in Practice: Auditing Models, Agents and Vendors
Regulatory Evidence in Practice
If your system falls under the EU AI Act as high-risk, the evidence pack becomes a regulatory artefact. Map each requirement to a control and an evidence item.
Risk management (Article 9). Evidence: the risk register, the assessment method, the residual risks, the review dates. Control: a documented process with an owner.
Data governance (Article 10). Evidence: the datasets used for retrieval or fine-tuning, the quality criteria, the bias checks, the provenance. Control: a data card per source.
Technical documentation (Article 11). Evidence: the system description, the design, the model, the intended use, the limitations, the instructions for use. Control: a maintained document with a version.
Record-keeping (Article 12). Evidence: automatic logs of the system's operation, retained for the required period. Control: logging that can reconstruct a transaction.
Transparency and instructions (Article 13). Evidence: the user-facing instructions, the limitations, the human oversight guidance. Control: published instructions that match the system.
Human oversight (Article 14). Evidence: the oversight design, the reviewer training, the sample of reviewed cases, the authority to stop. Control: oversight measurable in the workflow.
Accuracy, robustness, cybersecurity (Article 15). Evidence: the evaluation results, the adversarial tests, the fallback behaviour, the security controls. Control: the release gate and the monitoring.
The mapping is not the compliance. The evidence behind each row is. An auditor will sample the evidence and ask who signed it.
AI Governance in Practice: Auditing Models, Agents and Vendors
The First 30 Days for a New Governance Lead
If you inherit this function, do five things in the first month.
Week 1: find the systems. Pull the SSO logs, the procurement records, the cloud bills and the department surveys. Build the inventory with names and owners. Expect the list to double.
Week 2: tier the risk. Apply a simple tier: high if the system affects people, money, safety or compliance; medium if it is customer-facing with review; low if it is internal and reversible. Agree the tiers with risk.
Week 3: build one evidence pack. Choose the highest-risk system and complete the five layers. The gaps are your first findings, and the pack is your template.
Week 4: set the cadence and report. Agree the monthly review, the quarterly checks and the annual audit. Present the inventory coverage, the open findings and the decisions you need.
Do not start with a policy rewrite. Start with the systems, the evidence and the decisions. The policy can describe the operating model you have proven.
AI Governance in Practice: Auditing Models, Agents and Vendors
The Evidence Request List
When a customer, auditor or regulator asks for assurance, a prepared organisation answers with a standard pack. Keep the list short and the items current.
System register entry. Purpose, owner, risk tier, model and vendor, data classes, users.
Model card. Version, provider, intended use, limitations, evaluation summary, fallback.
Evaluation report. The golden set, the rubric, the scores, the severe errors, the slices.
Data flow. Sources, permissions, retention, location, subprocessors.
Oversight record. Who reviews, what they see, the sample, the training, the stop authority.
Release gate decisions. The last three changes, the evidence, the signer.
Incident log. Open and closed incidents, the containment, the remediation.
Vendor pack. Contract clauses, security evidence, subprocessor list, exit plan.
Audit findings. Severity, owner, date, status.
Framework mapping. Requirement, control, evidence, owner, version.
The pack is a folder, not a project. Assemble it once, keep it current, and the next request becomes a link instead of a scramble.
AI Governance in Practice: Auditing Models, Agents and Vendors
When the Regulator Arrives
The first contact is usually a request for information. The response has four rules.
Answer the question asked. A broad narrative invites more questions. Cite the specific system, the control and the evidence.
Do not overclaim. "We comply with the AI Act" is a claim that must be supported article by article. "Our high-risk system has these controls and this evidence, and these gaps with remediation dates" is defensible.
Keep a single source of truth. One register, one evidence pack, one mapping. Different answers from different teams are a finding in themselves.
Preserve the record. Log the request, the response, the date and the recipients. The regulator will ask for the history, and the history is evidence.
The same discipline serves a customer questionnaire and an internal audit. Prepare once, answer many times.
AI Governance in Practice: Auditing Models, Agents and Vendors
What Good Looks Like at Year One
A mature governance function is not measured by the thickness of its policy. At one year, six things are true.
The inventory is trusted. Every AI system has an owner, a tier and a current pack. Procurement cannot onboard a tool without a row. The list is used for decisions, not for audit season.
The gate is used. Changes are blocked when evidence is missing, and the block is normal. Teams plan for the evaluation because they know the gate will ask for it.
Findings are managed. Every finding has an owner and a date, and the ageing report is reviewed monthly. Severity 1 findings are rare because Severity 3 findings are fixed before they grow.
Oversight is measurable. The organisation can show review time, sample quality and escalation rates. It knows the difference between a human in the loop and a human in the room.
Vendors are managed. The critical vendors have current evidence, contractual change notice and a tested exit. Concentration is a known risk with a documented fallback.
The board is engaged. The board sees coverage, open findings, incidents and decisions. It has stopped or restricted at least one system, or it has explicitly accepted a residual risk. Governance without a decision is decoration.
None of this requires a large team. It requires a register, a gate, a cadence and an executive who signs. The rest is discipline.
AI Governance in Practice: Auditing Models, Agents and Vendors
What the Board Should Ask
A board does not need to understand model architecture. It needs to ask five questions that expose whether governance is real.
1. What can the system do without a human? The answer defines the blast radius. If the board hears "it drafts, a human sends", the risk is different from "it issues refunds up to fifty euros". Ask for the code-level control, not the intention.
2. What evidence do we have that it works on our cases? The answer should be an evaluation on your data, with a pass rate, a severe-error count and a date. A vendor benchmark is not evidence about your workflow.
3. Who can stop it, and have they tested the stop? The answer names a person, a mechanism and a date. If nobody has tested the kill switch, it is a plan.
4. What have we found and not fixed? The findings register, by severity, with owners and dates. An empty register after a first audit is suspicious, not reassuring.
5. What changed since the last report, and who approved it? Model versions, prompts, tools, vendors. The change log is the audit trail.
Ask the same five questions every quarter. The answers become the governance record, and the record becomes the evidence when a regulator or customer asks. A board that asks these questions creates the demand for evidence; a board that only approves budgets creates the demand for slides.
AI Governance in Practice: Auditing Models, Agents and Vendors
The Evidence Habit
The difference between a governed organisation and an audited one is the habit of producing evidence as the work happens.
Four habits build it. Capture the decision at the moment it is made: the gate record, the signer, the date, the evidence. Keep the evidence where the system lives, not in a separate folder that decays. Review the record in the monthly operating meeting, so the evidence stays current. And close findings with proof, not with a sentence in a status report.
Habits beat audits. An organisation that produces evidence continuously can answer any questionnaire in a day, pass an audit without a scramble, and learn from its own incidents. An organisation that produces evidence only when asked is always reconstructing the past, and the reconstruction is always incomplete.
The first year is the hard one. After that, the evidence is a by-product of running the system well, and governance becomes what it should be: the operating discipline that lets the organisation use AI faster, because the risks are known and managed.
AI Governance in Practice: Auditing Models, Agents and Vendors
Feynman Summary: Explain It Like You Are 12
Imagine your school lets a robot help in the cafeteria. Before the robot starts, the principal asks three questions: what exactly will it do, how do we know it does it safely, and who is allowed to stop it?
To answer, the school writes a list of every robot and what it is allowed to touch. It keeps the robot's instruction sheet and the results of the practice runs. It watches the robot for a week and writes down every mistake. And it names the person who can switch it off.
That is an AI audit. Not a promise that the robot is perfect, but a record that proves someone is paying attention, with evidence, before something goes wrong.
AI Governance in Practice: Auditing Models, Agents and Vendors
Mindmap: The Complete Picture
The mindmap shows the whole audit system: the inventory and evidence layers, the three audit types, the severity and remediation path, the cadence and the regulatory mapping.
UNOP Sound (University 365 Neuroscience Oriented Pedagogy)
Take five minutes to consolidate your memory. Play the isochronous tone track (10Hz alpha frequency) with your eyes closed. Alpha-frequency tones after a learning session support consolidation, helping move what you just learned from short-term to long-term memory.
[Audio player: UNOP Post-Lecture Isochrone (10Hz, 5 minutes)]
AI Governance in Practice: Auditing Models, Agents and Vendors
Practical Exercise: Build One Evidence Pack
Choose one AI system in your organisation. Build the pack for that system in five steps.
Inventory row. Name, purpose, owner, vendor and model, data classes, users, risk tier, status.
Model evidence. Version, your evaluation results on your own cases, known limitations, fallback.
System evidence. Prompts and versions, retrieval sources and permissions, logs, human review points, the last release decision.
Agent or vendor evidence. If an agent: tools, permissions, ten sampled traces, stop test. If a vendor: contract clauses, security evidence, exit plan.
Findings. Three gaps with evidence, severity, owner and date. One action you will take this week.
If the pack takes more than a day, the missing evidence is the finding. Record it and escalate.
AI Governance in Practice: Auditing Models, Agents and Vendors
Glossary
Term | Definition |
AI audit | A structured examination of an AI system in use, against a defined standard, with evidence |
Evidence pack | The folder of documents that proves a system's design, data, evaluation, oversight and controls |
Risk tier | The classification that sets the evidence, oversight and approval level for a system |
Model card | A document describing a model's version, intended use, limitations, evaluation and fallback |
Agent | A system that takes multi-step actions with tools rather than only producing text |
Blast radius | The maximum consequence of one error, enforced as a product and engineering constraint |
Subprocessor | A third party used by a vendor to process data as part of the service |
Concentration risk | The risk created when critical workflows depend on one provider, model or region |
Severity | The grade that determines the response time and authority for a finding |
Release gate | The rule that defines the evidence required before a change reaches users, and the signer |
Residual risk | The risk that remains after controls, which an accountable executive must accept |
Human oversight | The measurable human review, authority and recording that keeps a system accountable |
AI Governance in Practice: Auditing Models, Agents and Vendors
Quiz: TEST YOUR UNDERSTANDING
1. What distinguishes an AI audit from an AI policy?
A) It is longer
B) It produces evidence against a defined standard
C) It is written by legal
D) It covers only models
2. Why must an agent's action limit be enforced in code rather than in the prompt?
A) Prompts are slow
B) A prompt can be overridden by injected content, while code enforces the boundary
C) Code is cheaper
D) Prompts cannot be audited
3. Which evidence layer covers tool permissions, side effects and stop controls?
A) Model evidence
B) System evidence
C) Agent evidence
D) Vendor evidence
4. What four fields must every finding carry?
A) Title, author, date, version
B) Evidence, severity, owner, date
C) Risk, cost, benefit, decision
D) Model, prompt, data, output
5. What makes human oversight real rather than nominal?
A) A policy statement
B) Measured review time, evidence shown and authority to stop
C) A signature at launch
D) A training video
Answers: 1-B, 2-B, 3-C, 4-B, 5-B
Related Resources
U365 INSIDE Publications
External Resources
Related U365 Lectures (Coming Soon)
AI Risk Register: A Practical Framework for Any Organisation (Cross-Institute Series)
Human-in-the-Loop by Design: Escalation, Review and Accountability (Cross-Institute Series)
AI Vendor and Model Due Diligence (Business AI Series)
AI Governance in Practice: Auditing Models, Agents and Vendors
U.Copilot for This Lecture
You are my AI audit coach. I need to build an evidence pack for one system and prepare for a board review. System: [name and purpose] Owner: [name and role] Vendor and model: [provider, model, version] Data: [classes of data, sources, retention] Users and decisions: [who uses it and what it influences] Do six things: 1. Assign a risk tier and justify it against people, money, safety and compliance. 2. List the five evidence layers for this system, and mark what is missing today. 3. If it is an agent, list the tools, permissions and blast radius, and propose the controls that must be enforced in code. 4. Draft five audit questions for the vendor, with the evidence I should request. 5. Propose the findings register: evidence, severity, owner, date, for the three most likely gaps. 6. Write the one-page board summary: coverage, open findings by severity, incidents and the decisions required. Ask me one clarifying question before you start if the system or its decisions are ambiguous.
AI Governance in Practice: Auditing Models, Agents and Vendors
Next Steps
Add every AI system to one inventory with an owner, a purpose and a risk tier.
Build the evidence pack for the highest-risk system this month.
Move every agent action limit out of the prompt and into the tool layer.
Sample ten traces and measure whether human oversight is real.
Set the audit cadence and report the six board metrics at the next review.
AI Governance in Practice: Auditing Models, Agents and Vendors
IMPORTANT NOTICE
Copyright University 365, Inc. All rights reserved. This lecture is provided for educational purposes and does not constitute legal, financial or professional advice. For enrollment, visit university-365.com/tuition. For permissions or inquiries, contact uda@university-365.com.
Published by the Department of Academics, University 365.
Lecture delivered by the UIT, UIB, UIC, UID in collaboration.
Martin Swartz, Dean of Academics, UDA
Signed for the academic year 2026.
Comments