The Association of Governance, Risk and Compliance (AGRC) and US-based leading algorithmic auditing firm BABL AI launched a Level 3 Certificate in AI Risk Management and Compliance in March 2026. It is aimed at governance, risk, compliance, internal audit, legal and policy professionals who need to identify, categorise and control AI risk in their organisations. The Compliance Digest discussed AGRC’s ground-breaking certificate with BABL AI Founder and CEO Shea Brown, and its significance at a time when regulatory scrutiny is intensifying, accountability expectations are rising, and the cost of getting AI governance wrong is higher than ever.
One thing you have spoken about quite directly is the way generative AI is now being used to produce the very policies that are supposed to govern it. Someone can ask a model to draft a compliance policy in 30 seconds. How does the certificate inoculate professionals against producing that kind of paper-tiger documentation, and what tells you in an audit that a policy was actually written by a human who understood it?
This is something we see constantly in practice. The temptation is huge. The EU AI Act is here, you have a deadline, and a generative model will give you a 40-page policy in two minutes. The problem is that those policies are typically generic. They use the right words, they reference the right articles, but they have no relationship to how that organisation actually builds, deploys or governs its AI.
When we audit, you can tell almost immediately. The policy talks about controls that do not exist anywhere else in the organisation. It refers to a risk register nobody can show you. It references roles that have not been assigned to a real person. It says the AI governance committee will do something, and that committee has never met.
What we have built into the curriculum of this certificate is essentially a defensive posture against this. We do not start by writing the policy. We start with inventory. Where does AI actually live in your organisation? What does it touch? How is the risk distributed? Only when you have done that work, does a policy have anything real to attach itself to. And then the policy is short, it is specific, and it points at things you can verify.
The other piece is that we teach people to read a policy the way an auditor would. So, if you do choose to use a generative tool as a starting point, which is fine, you have the skills to interrogate what came out and ask whether any of it is actually true for your business.
Many of the professionals taking this certificate sit inside the business they are auditing. They are internal risk and compliance, they are internal audit, they have a manager who has a manager who has a target to ship the AI product. What does the certificate give them when leadership wants to green light a system they have concerns about?
This is one of the most under-discussed problems in AI assurance. The independence question is taken very seriously in financial audit, less so in AI right now, and the people we partner with through AGRC are very often the ones absorbing the pressure.
The honest answer is that no certificate can give somebody the political cover they need to disagree with a senior leader. What we can do, and what we have tried to do, is give them the language and the evidence base to make that pushback defensible. So when a head of product wants to ship a tool that scores CV applications, the person sitting across the table from them should be able to say: here are the specific risks I have identified, here are the controls we do not yet have, here are the regulations this could trigger, and here is the precedent from other organisations that have got this wrong. That is a very different conversation from ‘I have a bad feeling about this’.
We also spend time on documentation. If you raise a concern, it needs to be recorded. If your concern is overridden, that override needs to be recorded. Because the question that comes up six or 12 or 18 months later, when something has gone wrong, is who knew what and when. A professional who has done this certificate should be very clear on creating that paper trail without it becoming adversarial.
The longer answer is that organisations are going to need to think about this structurally. Where does AI risk reporting sit? Who does it report to? Does it report through the business it is auditing? These are questions a mature organisation needs to solve, and our learners are often the ones who have to start asking them.
Most current AI governance still assumes a system that makes a recommendation and a human who acts on it. With agentic AI now moving into production, that is changing. Systems are taking actions. They are sending emails, executing transactions, opening tickets. What specifically about the curriculum prepares people for that shift?
This is the frontier and I will be honest – we are all working it out as we go. The fundamental shift is that with a recommender system, you can put a human in the loop and that human is the last line of defence. With an agent, the action has already happened by the time you find out about it. Your controls have to move upstream.
What we have tried to do in the curriculum is force people to think in terms of what we call the CIDA model: Context, Input, Decision, Action. Every AI system, agentic or not, sits in a context, takes an input, makes a decision, and produces some kind of action. With agents, the action piece is no longer mediated by a human, so the controls have to shift to constraining what actions the system is permitted to take, what tools it has access to, and what guardrails sit between its decision and its execution.
For a compliance professional, that means asking different questions. It is not ‘did the human review the recommendation’. It is what is the agent allowed to do without authorisation, what is it not allowed to do under any circumstances, and how do you verify in production that those constraints are holding. Logging becomes critical. Reversibility becomes critical. The blast radius of a single agent action becomes a thing you have to assess before deployment.
The certificate does not turn anyone into a red teamer overnight. What it does is give people a vocabulary for these conversations and a structured way of thinking about where the controls need to live. We are going to keep iterating on this material because the technology is moving faster than the regulations are.
Across most organisations, employees are now using AI tools that compliance and IT have never approved. ChatGPT, Claude, Copilot, and dozens of others. The official policy says one thing and the actual behaviour is another. Does the certificate give professionals a practical playbook for surfacing and governing the AI they do not yet know about?
Yes, and this is probably the single most common gap we see when we walk into an organisation. Leadership says ‘we do not really use AI yet’, but then you spend 10 minutes talking to the people who actually do the work and you discover that everyone in marketing is using a generative tool for first drafts, the HR team is summarising CVs with ChatGPT, finance is using something to format reports, and nobody has told anyone.
The first thing we teach is that this is normal and it is not going to be solved by a policy that says you cannot. People will use these tools because they are useful and because their job depends on getting things done. The intervention has to be different.
You need a discovery exercise. We give people a method for doing a structured walkthrough of every business function in the organisation and surfacing what is actually in use. You would be amazed how much shows up when you ask the right questions.
The second thing is risk triage. Most shadow AI use is probably low risk. Somebody using a tool to draft an email is not the same as somebody piping customer data into an unvetted model. You have to be able to separate those quickly, because if you treat them the same way you will lose the trust of the business, and they will just stop telling you what they are doing.
The third thing is creating sanctioned paths. People will respect a policy that says here are the tools you are allowed to use, here is how to ask for a new one, here is the answer turnaround. They will not respect a policy that just says no. The certificate is very practical on this point.
Many of the professionals taking the certificate work for organisations that do not build AI, they buy it. They are licensing it, embedding it, working with vendors who themselves are using other vendors’ models. How does the curriculum handle that supply chain reality?
The vendor question is enormous and it is underestimated. The chain of accountability when something goes wrong is genuinely complicated. You have a foundation model provider, a company that fine-tuned it, a systems integrator that wrapped it, a vendor that sold it to you, and your own deployment context which the model was probably never tested against.
The curriculum approaches this in a couple of ways. The first is teaching people what questions to ask in a procurement process. There is a set of basic things you should be getting from any AI vendor before you sign. What model is it built on? Has it been independently evaluated? What is the testing methodology? What happens when the underlying model is updated, do you get notified? What contractual rights do you have to audit performance? Most procurement teams do not currently ask any of these.
The second is teaching people that you do not get to outsource your accountability. Under the EU AI Act, if you are a deployer of a high-risk system, you have obligations regardless of who built the system. The same is true under emerging US state laws. So, the question is not whether the vendor is compliant, it is whether your use of the vendor’s product is compliant.
The third piece, which is harder, is ongoing monitoring. The system you bought is not the same system you will have in twelve months. The model behind it will have been updated, possibly several times. You need a relationship with the vendor that gives you visibility into those changes. We walk through some practical contract language and some monitoring practices that learners can take straight back into their work.
What is an AI failure or near-miss from the last 12 months that has most influenced how you teach risk professionals, and what is the one lesson you want every certificate-holder to take away from it?
I will keep it generic but the pattern is one we have now seen multiple times. An organisation deploys a generative tool into a customer-facing process. The tool has been tested. There is a policy. There is a sign-off. Months later it starts producing outputs that are wrong, sometimes confidently wrong, sometimes in ways that have direct financial or legal consequences for the customer.
The investigation reveals that the model behind the tool was silently updated by the provider, the testing was never repeated, the monitoring would have caught it if anybody had actually looked at the dashboards, and the policy did not define who owned that monitoring on a day-to-day basis.
The lesson is that deployment is not the end of the work, it is the start. And ownership of an AI system in production needs to be assigned to a named human being, not to a function. If you ask who is responsible for making sure this system continues to behave as expected, the answer needs to be one person with that as part of their job description, not the risk team in the abstract.
The other lesson, which I would want every certificate-holder to internalise, is that the most dangerous AI failures are quiet ones. The system does not crash. It does not throw an error. It just starts being slightly wrong, at scale, for a long time before anybody notices. So, your monitoring needs to be designed for drift, not just for breakage. That is a shift in mindset for a lot of risk professionals who are used to incident-driven work.
Once somebody has completed this certificate, what should they realistically be doing differently in their organisation six months later? And longer term, what does the career arc look like for somebody who wants to go deeper?
Six months out, the realistic picture is that they should be the person their leadership turns to when an AI question comes up. They should have run or contributed to an AI inventory exercise. They should have a working understanding of which of their organisation’s AI uses fall into which regulatory categories.
They should have started building, or be actively maintaining, a risk register that includes AI-specific entries. And they should be able to sit in a meeting with engineering or product and ask intelligent questions about how a system was trained, evaluated and monitored.
What I would not expect is that they become the person who does the technical evaluation themselves. That is a different skill set, and we have a separate pathway at BABL for people who want to develop those hands-on testing capabilities.
Longer term, the career arc has at least three branches I would point people at. The first is internal, becoming the head of AI risk or the equivalent role in their organisation. These roles barely existed three years ago and they are proliferating now. The second is external, moving into AI assurance and auditing firms, which is the path we follow at BABL. The third, and this is one I would encourage more people to think about, is regulatory and policy work. Regulators urgently need people who understand both compliance practice and AI, and that intersection is rare.
What I would say to anybody starting this journey is that you do not need to have a computer science background. The most effective AI risk professionals I work with come from audit, from legal, from operational risk, from anywhere there is a habit of asking how things actually work. The technical material is learnable. The instinct for risk is harder to teach.
The EU AI Act’s AI literacy requirements under Article 4 have been in force since February 2025. Many organisations are still working out what compliance with that even looks like. How does this certificate sit within an organisation’s defensible AI literacy programme?
Article 4 is one of the under-discussed pieces of the EU AI Act because it does not have the sharp teeth that some of the other articles have, but it applies to everybody. Any provider or deployer of an AI system in scope has to ensure that staff who interact with it have a sufficient level of AI literacy. The regulation is deliberately principles-based, so organisations are scrambling to define what ‘sufficient’ actually means.
The way I would position this certificate is that it is an excellent fit for a specific population within an AI literacy programme. It is not a literacy programme for every employee. It is the deeper, role-specific layer for the people in governance, risk, compliance, internal audit, legal and policy who need to do more than understand what AI is. They need to be able to identify it, categorise the risk, and articulate the controls.
A defensible literacy programme typically has at least three layers. There is a general awareness layer for the whole workforce, which is short, accessible and broad. There is a developer layer for people building systems, which is technical. And there is a governance layer for the people who oversee and control, and that is the layer this certificate sits in.
What I would caution against is treating any single course, ours included, as the complete answer for an organisation. Literacy is ongoing. The regulation knows that. The technology will move, the threat landscape will move, and your literacy programme has to be a living thing. This certificate is a strong foundation, but the people you put through it should not be the last training they receive on the topic.
One thing GRC professionals consistently tell us is that they have 10 minutes with the board or the executive committee to walk them through an AI risk decision. The board does not want a technical lecture and they do not want a checklist. They want a judgement. Does the certificate teach that translation layer between technical evaluation and boardroom judgement?
This is one of those things that does not get enough attention in technical AI training, and we made a deliberate decision to address it. The translation problem is real. A board member does not need to understand what a transformer is. They need to understand what the organisation is exposed to, what is being done about it, and what residual risk they are being asked to accept.
The framework we teach is essentially three things. What is the system doing for us? What could go wrong, expressed in terms the board already cares about, which is financial, reputational, legal and operational? And what controls are in place, with an honest assessment of where the gaps are?
What I would push people away from is the temptation to be reassuring. Boards have got quite good at sensing when somebody is sanding the edges off a risk picture for them. The most effective boardroom AI briefings I have seen are the ones that are slightly uncomfortable to deliver. They name what the organisation does not yet know. They flag the systems that have not been assessed. They give the board the chance to make a real decision about appetite, rather than just acknowledging a sanitised summary.
We have learners practise this in the certificate. They draft a board paper. They present a five-minute summary. They get feedback on whether they have used jargon a non-technical reader would not understand, whether they have quantified the risk in useful terms, and whether they have left the board with a decision to make. It is a skill, and it is one of the most useful things somebody can take from this programme.
Could you expand a bit more on the boundaries of what this certificate does and does not give prospective learners. You have launched the AI Test, Evaluation and Red Teaming bootcamp, and there is a full specialist certification due later this year. How should somebody think about the AGRC certificate as part of a wider learning pathway?
Over-promising on a certificate does nobody any favours. This certificate is designed for a specific person and a specific job. It is for governance, compliance, risk, internal audit, legal and policy professionals who need to identify, categorise and control AI risk in their organisations. That is a substantial body of knowledge and skill, and the certificate covers it well.
What this certificate is not is a technical assurance qualification. If you want to be the person who actually sits down with a model, designs a test plan, runs evaluations and red teams the system, that is a different skill set and it requires different training. That is exactly what we built the AI Test, Evaluation and Red Teaming bootcamp to address, and there is a full specialist certification following on from it late Q4-2026. In the meantime, you can look at our other courses here. (AGRC members get a 30% discount until the end of 31st August 2026 using code ‘AGRC30’ at checkout).
The way I would describe the pathway is that the AGRC certificate gives you the governance and risk management lens. The BABL technical track gives you the hands-on evaluation capability. Most organisations need both, but most individuals will lean towards one or the other based on their background and their inclination.
What I would say to anybody considering this certificate is do not take it as a one-off. Take it as the foundation, then look at what the next step is for you. For most learners, the next step is doing the work, going back to their organisation, applying what they have learned, and seeing where the gaps in their own practice show up. That is when you know what the next piece of training should be. And we will be there with it.
Shea Brown is the founder and Chief Executive Officer of BABL AI, a research consultancy and AI audit and assurance firm focused on algorithmic auditing and AI governance. He leads a company that has been auditing and certifying AI systems since 2018, ensuring algorithms are developed and deployed in ways that prioritise human flourishing and avoid discrimination. Dr. Brown is a researcher, lecturer, speaker, and consultant in AI Ethics, Machine Learning, and Astrophysics, with a specialised focus on algorithmic auditing and AI governance. He holds a Doctor of Philosophy (Ph.D.) in Astrophysics from the University of Minnesota (2005–2009), where he was a PhD student, and also earned a Master of Science from Brandeis University. His academic career included 11 years at the University of Iowa, where he served as Associate Professor of Instruction in Astrophysics (2018–2022) and Lecturer (2012–2018) before stepping away in 2024 to focus fully on BABL AI. He also completed a postdoctoral fellowship at CSIRO (2009–2012). He is a ForHumanity Fellow and Certified Auditor (FHCA), a founding member of the International Association of Algorithmic Auditors (IAAA) and has been recognised on the Engatica list of the World’s Top 200 Business & Technology Innovators (2024).
