Episode 15 — Write AI security policies people can follow without guessing (Task 2)
In this episode, we build a clear way to tell the difference between an A I idea that is sensible and manageable and an A I idea that is high risk and needs stronger controls or a different approach. Beginners often assume high risk means the model is complicated, but risk is not only about complexity. High risk is about what happens when the system is wrong, how likely mistakes are, how easy it is to detect and correct those mistakes, and whether the organization can govern the system responsibly over time. A simple recommendation engine for movie suggestions might be technically complex and still be relatively low risk, while a very simple model used to deny someone a benefit could be high risk because consequences are serious. Audit logic helps you separate these because it forces you to evaluate impact, evidence, and governance rather than relying on impressions. Task 1 is about evaluating A I solutions early, and one of the most valuable early outcomes is correctly classifying a proposal’s risk level so the organization chooses appropriate safeguards. By the end, you should be able to hear an A I proposal and explain, in plain language, why it is a good idea with manageable risk or why it is high risk and requires stronger oversight.
Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.
The first audit lens is impact level, because impact is what turns a technical error into a business and human problem. Impact asks who is affected, what is affected, and how severe the consequences are if the system fails or is misused. If the output influences hiring, lending, healthcare, safety, legal rights, or access to essential services, impact tends to be high because mistakes can cause lasting harm. If the output influences internal efficiency decisions with easy human correction, impact may be lower even if mistakes are frequent. Impact also includes scale, meaning how many decisions the system will touch and how quickly it can affect people. An A I system that makes a few suggestions a day carries different risk than a system that makes thousands of automated decisions per hour. Another impact factor is reversibility, meaning whether a bad decision can be easily undone or whether it causes irreversible harm, like denying a critical medical intervention. Auditors focus on these impact dimensions because they determine how strict requirements, validation, monitoring, and human review should be. A good idea A I use case often has limited impact, strong reversibility, and clear paths for correction, while high-risk use cases amplify harm and reduce the safety margin.
The second audit lens is decision authority, which means how much power the model’s output has in the real workflow. A low-risk pattern is decision support, where the model provides a recommendation but humans make the final call and understand how to challenge the output. A high-risk pattern is decision automation, where the model output directly triggers an action such as denial, approval, or enforcement, especially when people do not have a meaningful way to appeal or when oversight is weak. Many proposals sound like decision support but quietly become automation over time because teams rely on the model to save effort. Audit logic treats that drift as a risk, because reliance increases the impact of model errors and reduces human skepticism. Another factor is whether the model output is understandable to the user, because opaque outputs encourage blind trust. If the model produces a single score with no context, people often treat it as a verdict, and that can turn a moderate-risk use case into a higher-risk one. A good idea A I use case often includes clear decision boundaries, such as when human review is required and when automation is prohibited. High-risk proposals often lack those boundaries or treat them as optional.
The third lens is evidence readiness, which is the organization’s ability to prove that the system is fit for purpose before it is relied on. Evidence readiness includes whether requirements are defined, whether success measures and thresholds exist, whether validation is realistic, and whether fairness and safety checks are planned where appropriate. A proposal is higher risk when stakeholders cannot articulate what acceptable performance means or how they will test it, because that signals the organization is depending on hope. It is also higher risk when the data story is unclear, such as not knowing what data will be used, whether permissions exist, or whether labels represent reliable ground truth. Auditors care because A I systems can be persuasive, and without evidence discipline, persuasive systems can cause harm while appearing successful. Evidence readiness also includes documentation and traceability, because in high-impact contexts, the organization may need to explain decisions and justify controls to regulators, customers, or internal leadership. A good idea A I proposal usually comes with a clear evidence plan, even if the details will be refined, while a high-risk proposal often has a vague plan like we will test it and see.
The fourth lens is control readiness, which means whether the organization has the governance and operational controls needed to manage the system over time. Control readiness includes ownership, approval processes, monitoring, escalation, incident handling, and change management. A system can begin as a good idea and become high risk if controls are missing, because the absence of controls means problems will not be detected and corrected quickly. Monitoring is especially important because models can drift as data and behavior change. If a proposal includes no clear monitoring metrics, no triggers for action, and no accountable owner for response, audit logic flags it as high risk regardless of how impressive the model appears. Control readiness also includes access control, because sensitive data and model behavior must be protected from unauthorized access and changes. It includes version control and audit trails, because when issues arise, the organization must be able to reconstruct what happened and which version produced which outcome. A good idea A I proposal often includes practical controls that match the impact level, while high-risk proposals often assume controls will be figured out later, which is a dangerous assumption.
A fifth lens is sensitivity to context change, because some A I uses are inherently more stable than others. A model that detects a stable pattern in a controlled environment may remain reliable longer, while a model that depends on fast-changing behavior, like fraud patterns or social trends, may degrade quickly. High sensitivity increases risk because it increases the need for frequent monitoring, retraining, and governance. Another context factor is how messy the inputs are. If the model depends on unstructured text from users, the input quality can be unpredictable, increasing error likelihood. If the model depends on sensor data in variable conditions, like lighting or weather, it may be sensitive to environmental shifts. Auditors consider this because stability affects how easy it is to maintain safe performance. A good idea A I use case often has inputs and environment that are reasonably stable or has strong safeguards for instability. High-risk use cases often combine high impact with high sensitivity, which is a particularly dangerous combination because both severity and likelihood rise. When you see that combination, audit logic pushes toward stronger controls or reconsideration of the use case.
Let’s apply these lenses to two contrasting examples to make the difference feel concrete. First, imagine a system that suggests which internal knowledge articles a support agent should read while helping a customer. The impact is moderate because the agent can ignore the suggestion and still use judgment. Decision authority is low because it is advisory, not automatic. Evidence readiness is achievable because you can measure whether suggestions improve resolution time without directly denying service. Control readiness can be manageable because the system does not need to make final decisions, but monitoring is still useful to detect poor suggestions. This looks like a good idea A I use case because it supports humans and is reversible when wrong. Now imagine a system that automatically denies customer refunds based on predicted fraud risk. Impact is high because it affects money and fairness, and it can damage trust. Decision authority is high because the system triggers denial, and appeals may be difficult. Evidence readiness must be very strong, including fairness testing and clear thresholds, because errors have serious consequences. Control readiness must be strong because monitoring, escalation, and accountable ownership are essential. This looks like a high-risk use case because it combines high impact with high authority, and the harm of mistakes is significant.
A common beginner mistake is to treat high-risk A I as something you avoid completely, but audit logic is more nuanced. High-risk does not always mean no, it often means not yet or not without safeguards. The audit mindset is to adjust the control environment to match risk, and sometimes the right answer is to redesign the use case to reduce authority and increase human review. For example, instead of automatically denying refunds, the model could flag high-risk cases for human review, reducing decision authority while still delivering value. Another approach is to limit scope to a low-impact subset, such as using automation only for very small amounts or only for cases with strong corroborating evidence. You can also strengthen transparency and appeals processes so that when the system is wrong, harm can be corrected quickly. The exam often tests this kind of thinking by offering answers that either embrace automation blindly or reject A I entirely, while the best answer is a controlled middle path grounded in evidence and governance. Beginners should learn that audit logic is about matching controls to risk, not about reflexively saying yes or no.
Another important point is recognizing when a proposal is high risk because of the organization’s maturity, not because of the use case itself. The same use case can be manageable in an organization with strong data governance, monitoring practices, and clear accountability, and be high risk in an organization without those foundations. If an organization cannot track model versions, cannot control access, and cannot respond to monitoring alerts, then even moderate-impact A I can become high risk. Auditors therefore evaluate both the system and the organizational capability to govern it. This is why earlier episodes about requirements, enterprise architecture fit, and hidden assumptions matter so much. A proposal that relies on data quality that does not exist, or on monitoring that nobody owns, is high risk because the organization cannot control it. On the exam, you may see scenarios where the technical idea seems reasonable but the governance is weak. The audit-aligned answer often focuses on strengthening governance and controls before expanding use, rather than debating model sophistication.
As we close, remember that separating good idea A I from high-risk A I is a structured judgment based on impact, decision authority, evidence readiness, control readiness, and sensitivity to context change. Good idea A I tends to support humans, remain reversible, have measurable benefits, and fit within existing governance capabilities. High-risk A I tends to make or heavily influence high-stakes decisions, operate at scale, be hard to explain or challenge, and require strong controls that may not yet exist. Audit logic does not treat high risk as a label meant to scare people, it treats it as a signal that governance, validation, monitoring, and accountability must be stronger or that the use case should be redesigned. In the next episode, we will evaluate A I impacts on system interactions and upstream dependencies, because hidden dependencies can quietly move a use case from good idea to high risk. For now, practice using the lenses: ask who is affected, how much authority the model has, what evidence proves readiness, what controls sustain safety, and how stable the environment is over time.
