Ai-Risk-Assessment |

Implementation Tips for ISO 42005 AI Impact Assessments

Thu, 12 Mar 2026 00:00:00 +0000

Why the ISO 42005 AI Impact Assessment Structure Matters

Most AI impact assessments fail before the first risk is even discussed.

They fail in the form itself. Teams rush through fields, paste in vendor language, skip foreseeable misuse, and treat ISO 42005 as a documentation exercise instead of a decision tool. Then the assessment gets approved with gaps large enough to drive a regulatory inquiry through. I have seen this happen in hiring, fraud, customer service, and internal productivity tools. The pattern is always the same. The template exists, but nobody has turned it into an operational workflow.

That is why this post matters. If you want an AI impact assessment that actually helps governance, you need more than a list of ISO 42005 fields. You need a working method for what to write, who owns each section, what evidence should sit behind it, and where common failure points show up. This guide gives you that method.

Suggested visual: A one-page lifecycle view showing ISO 42005 fields mapped to intake, design review, testing, approval, deployment, and monitoring.

Understanding the Core Concept for ISO 42005 AI Impact Assessment Fields

ISO 42005 gives structure to an AI impact assessment. That structure is useful because AI projects drift fast. Functionality changes. Users change. Risk changes. Jurisdictions change. If the assessment does not capture those moving parts clearly, governance loses the thread.

Here is the mental model I use. Every good ISO 42005 AI impact assessment should answer four questions.

What is the system?

Why does it exist?

Who can it affect?

What evidence shows the risks were taken seriously?

Those four questions map directly to the field groups in the standard. General information tells you what document you are looking at and whether it is current. System description and purpose explain the tool and the claimed value. Data, model, deployment, and parties sections reveal who and what are in scope. Benefits, harms, failures, and misuse force teams to confront consequences.

Most organizations struggle because they fill out fields one by one without connecting them. That creates contradictions. The “basic description” says the model offers recommendations only, while the intended use says it can auto-route claims, and the harms section forgets due process entirely. I have reviewed assessments where three different teams described the same AI system in three different ways. Nobody noticed until the approval meeting.

Original implementation tip: Start every ISO 42005 AI impact assessment with a 30-minute alignment session across product, engineering, legal, privacy, and the business owner. Put the core use case on one page before anyone touches the template. This cuts inconsistency fast.

The five field groups that matter most

You should complete every section. Still, five groups carry most of the practical weight.

1. Identity and governance fields

These include AI system name or ID, lifecycle stage, revision history, reviewer, and approver fields. They sound administrative. They are not.

These fields tell you whether the document is current, whether the system being assessed is the actual system going live, and whether the right people stood behind the review. In one client review, the version approved by governance was two model versions behind the one engineering deployed. The mismatch only surfaced because the revision dates were inconsistent.

Original implementation tip: Tie the AI system ID in the assessment to the product registry, model registry, and procurement record. If those IDs do not match, stop the review until they do.

2. Scope and use fields

These include the system description, functionalities, purpose, intended uses, unintended uses, and dependencies. This is where teams often understate what the system does.

A chatbot may summarize, infer sentiment, draft responses, detect abuse patterns, and pass outputs into another workflow. A hiring tool may rank candidates, reject applicants, generate recruiter notes, and capture video data. If only one of those functions is named, the assessment underestimates impact.

Original implementation tip: Require every functionality field to begin with an action verb such as classify, predict, rank, generate, summarize, identify, or recommend. Vague descriptions hide risk.

3. Data and model evidence fields

These cover datasets, data quality, algorithm suitability, model evaluation, drift, retraining, and bias or harms testing. This is where technical evidence enters the impact assessment.

Weak assessments use placeholders here. Strong ones provide actual data lineage, performance metrics, subgroup testing, and retraining criteria tied to operating conditions. If you do not know what data shaped the model or how well it performs on the populations you will affect, the rest of the assessment is guesswork.

Original implementation tip: Add a rule that no field in this section can be answered with “standard process followed.” Ask for specifics, dates, metrics, and sign-off sources.

4. Deployment and affected-party fields

These include geography, legal requirements, culture, at-risk groups, languages, deployment constraints, and relevant interested parties. This is the section that grounds the system in the real world.

I once reviewed a language model deployment where the product team had tested English well and Spanish moderately, but the planned deployment included Arabic support by default in the interface settings. Nobody had validated it. The deployment field forced the issue. That one line probably prevented a bad launch.

Original implementation tip: Treat every new geography, language, and user group as a change in risk, not a scaling detail. Reopen the impact assessment when any of those variables expands.

5. Benefits, harms, failures, and misuse fields

These are the fields teams fear because they force honesty. Good. That is their job.

If your AI system could expose personal data, reinforce discrimination, suppress lawful speech, create unsafe recommendations, or be repurposed for surveillance or fraud, say so clearly. A useful AI impact assessment is not a sales deck.

Original implementation tip: Ask teams to write one foreseeable harm that would make the project sponsor uncomfortable. If every harm sounds minor and generic, the assessment is not mature enough.

Stage 1: Complete the General Information Fields Like They Matter, Because They Do

The first section of ISO 42005 is usually treated as setup. That is a mistake.

The responsible parties here are the business owner, product manager, governance team, and document owner. The accountable person should be the system owner, not a rotating project coordinator who cannot answer questions later.

The key artifacts are the AI system registry entry, lifecycle record, approval workflow, and document control log. These should all connect to the impact assessment fields for name, ID, lifecycle stage, revision history, review, and approval.

What to implement: For AI System Name or ID, use the same identifier that appears in procurement, architecture, model ops, and incident management records. For AI System Life Cycle Stage, use a controlled list such as concept, design, development, validation, pilot, production, material change, retirement. For review and approval fields, record named roles and dates, not generic team labels alone.

This is where many governance programs quietly break. A draft assessment gets copied from an earlier version. Dates remain old. Reviewer names remain wrong. The document looks complete, but nobody can prove who assessed the live version.

I made this mistake early in my consulting work. We had a clean-looking impact assessment packet for a vendor tool. During a later incident review, we discovered the “approved” file belonged to the pilot, not the scaled deployment with new features. Same product family. Different risk. We had to reconstruct the review trail by hand. It took days.

Original implementation tip: Add one field internally that ISO 42005 does not spell out but every program needs, “Material change since last assessment.” If the answer is yes, force a short summary of what changed and whether prior approvals still apply.

Stage 2: Write a System Description That Exposes Real Scope

The AI system description, functionalities, purpose, intended uses, unintended uses, and dependencies form the backbone of the assessment. If this section is weak, every later section becomes distorted.

Responsible parties include product, engineering, enterprise architecture, procurement for vendor tools, and governance. Legal and privacy should review wording for scope and consequence, but product and engineering must own the factual details.

The critical artifacts are the architecture diagram, user flow, API map, vendor documentation, and intended use statement. These artifacts should support every field in this section. If the description says the system does not make decisions, the user flow should not show auto-rejection or auto-escalation without human review.

What to implement: The Basic AI System Description should answer five plain questions. What input goes in. What output comes out. Who uses it. What decisions it influences. What other systems it sends information to. For functionalities, separate current features from planned ones and include estimated dates only when there is actual roadmap evidence.

For intended uses, describe the end user, setting, and boundaries. “Customer support summarization for trained internal agents in English-language email workflows” is strong. “Support automation” is weak. For unintended uses, list both malicious misuse and predictable overreach. A sentiment model used for employee wellness may later be repurposed for performance management. That risk belongs in the form.

Dependencies matter more than teams expect. If your AI output triggers another model, a business rule engine, a human review queue, or an external API, say so. Dependencies create hidden failure chains.

Original implementation tip: Add one internal control question under dependencies, “If this dependent system fails, what does the AI system do next?” Quiet fallback logic causes real harm. A ranking tool that defaults to a raw score when an explanation service fails can confuse reviewers and distort outcomes.

Stage 3: Treat Data Information and Quality as an Evidence Section, Not a Narrative Section

This section is where ISO 42005 gets serious. Dataset names, ownership, access rights, provenance, bias risks, quality processes, DPIA need, and data quality characteristics all belong here.

The responsible parties are data engineering, data governance, privacy, security, machine learning teams, and the business owner. If a vendor provides the model or training data, procurement and vendor risk teams should support the response.

The critical artifacts are data inventories, lineage records, access control logs, data use approvals, privacy assessments, quality reports, and retention schedules. A mature program can point to each one within minutes.

What to implement: For each dataset, document the owner, version, size, collection period, geography, whether data is real or synthetic, who collected it, under what authority, and whether its use for AI has been approved. Then document known bias risks and the exact quality checks performed. If a DPIA is required, mark it and link the reference.

For data quality characteristics met, name the characteristic and explain why it matters to the system. Completeness, representativeness, timeliness, label reliability, and class balance are common examples. For planned characteristics, do not write aspirations like “improve diversity.” Write the specific gap, why it matters, and the date by which the gap will be addressed.

I have seen teams write “dataset is representative” with no evidence. Then you look closely and find the data over-indexes one region, one user segment, or one language. The assessment should force teams to confront those limits, not glide past them.

Original implementation tip: Make teams state one thing the dataset is bad at. This sounds small, but it changes the tone of the whole assessment. Honest limitations produce better controls than polished claims.

Stage 4: Use the Algorithms and Models Section to Show Decision-Quality Evidence

This is the most technical part of the ISO 42005 AI impact assessment. It is also where non-technical reviewers often get lost.

The solution is simple. Write technical truth in plain language.

Responsible parties here are data science, machine learning engineering, model risk, security, privacy engineering, and domain experts. Governance should review for completeness and clarity, not rewrite the science.

The critical artifacts are experiment logs, validation reports, model cards, bias assessments, robustness tests, red team outputs, retraining standards, and compute or environmental records. If these artifacts do not exist, the fields will become vague. That is the signal to stop and fix the process.

What to implement: For algorithm suitability, explain why the chosen method fits the business task and the decision stakes. For validity and real-world performance, include prior deployments, known limitations, and evidence from published research or internal testing. For susceptibility to undesirable outcomes, name issues such as overfitting, spurious correlations, instability, proxy discrimination, hallucination, or prompt injection risk.

For model fields, document training, validation, and testing data. Explain how you kept datasets disjoint. Describe feature selection criteria. List performance metrics with thresholds tied to use case risk. Include generalization testing on production-like data. Add bias and harm evaluations, PII leakage checks, robustness measures, drift detection methods, retraining triggers, and impacts from continuous learning if used.

One practical point. Do not flood the form with every metric the team has. Pick the metrics that matter for the use case. For a classifier, that may be false positives and false negatives by subgroup. For a recommender, ranking quality and harmful amplification indicators may matter more. For generative AI, factuality, refusal consistency, privacy leakage, and unsafe output rates may be central.

Original implementation tip: Require every model section to include one sentence beginning with “This model should not be used when…” That sentence often reveals more practical governance value than two pages of metrics.

Stage 5: Ground the Assessment in Deployment Reality and Affected People

A model can perform well in testing and still fail in deployment because the geography, language, legal setting, or user population changes.

This section includes current and planned deployment areas, geo-specific legal requirements, cultural considerations, marginalized groups, languages, human traits relevant to the system, deployment method, and deployment constraints. It also includes internal and external interested parties.

Responsible parties include product, legal, privacy, public policy, regional operations, accessibility specialists, and frontline operational leaders. If the tool affects workers, patients, students, claimants, or citizens, the relevant operational function needs to be in the room.

What to implement: For geo areas, do not list countries only. List states, provinces, or cities when local law matters. For legal requirements, include labor law, data protection rules, sector rules, biometrics restrictions, consumer protection, and language access obligations where relevant. For marginalized groups, name the groups likely to be affected in that deployment context and explain why.

For interested parties, separate those who use the system from those subject to its outputs. A customer service agent using an AI assistant is not the same as the customer whose case is summarized and routed. An HR recruiter using a ranking tool is not the same as the applicant filtered by it.

I once worked on a case where the internal party list was detailed and the external party list was almost blank. That told us everything we needed to know about the maturity of the review. The team had thought about internal workflow efficiency and barely considered the people outside the company who would bear the impact.

Original implementation tip: If you cannot identify at least one external party who could be harmed, the assessment is probably too shallow. Nearly every deployed AI system affects someone beyond the immediate operator.

Stage 6: Write Benefits, Harms, Failures, and Misuse with Operational Honesty

This section is where the ISO 42005 AI impact assessment stops being descriptive and becomes evaluative.

The fields cover accountability, transparency, fairness and discrimination, privacy, reliability, safety, explainability, and environmental impact. Then they move into failures and misuse. This is where the assessment should show that the team has looked past the happy path.

Responsible parties include governance, legal, privacy, security, product, trust and safety, domain experts, and the business owner. If the use case is high impact, escalation to a risk committee makes sense.

What to implement: For each benefit field, describe a realistic gain tied to actual operations. For each harm field, describe a reasonably foreseeable downside with enough specificity to inform controls. Then document at least two failures and two misuses with impacts on interested parties.

A good example. For fairness and discrimination harms in a hiring tool, write that historical training data may reduce interview rates for women returning from caregiving gaps or for disabled applicants whose career patterns differ from prior hires. For misuse, write that recruiters may use the ranking score as a rejection tool despite policy saying it is advisory. That is a foreseeable misuse because people under time pressure take shortcuts.

This section should connect directly to approval conditions. If you identify a privacy harm, where is the retention control. If you identify explainability harm, where is the user notice or appeal workflow. If you identify misuse risk, where is the training or restriction.

Original implementation tip: Ask the frontline operators what misuse they fear. They usually know before governance does. The people who work the queue see where the shortcuts, workarounds, and pressure points really are.

Tips for ISO 42005 AI Impact Assessment

These tips apply across the whole assessment. They keep the form useful over time.

Tip 1: Do not let one team write the whole assessment alone

Single-author assessments look neat and miss reality. Product sees value. Engineering sees architecture. Legal sees obligations. Operations sees failure conditions.

Original implementation tip: Assign section ownership by expertise, then run one editor across the final document for consistency. Shared drafting with single-point editing works well.

Tip 2: Use evidence links, not long pasted explanations

Teams often turn impact assessments into bulky documents full of copied text. That slows review and hides gaps.

Original implementation tip: Keep field answers concise and link to source artifacts such as DPIAs, test reports, architecture diagrams, or validation files. Short answers with evidence age better than long prose.

Tip 3: Reopen the assessment at known trigger points

An AI impact assessment is not a one-time event. It should reopen when the system changes in material ways.

Original implementation tip: Set mandatory reassessment triggers for new data sources, new model versions, new geographies, new user groups, new decision rights, major incidents, or a shift from advisory use to automated action.

Tip 4: Separate “unknown” from “not applicable”

These are not the same thing. One means you have a gap. The other means the field genuinely does not apply.

Original implementation tip: Ban blank fields. Use a controlled response set such as completed, not applicable, unknown pending evidence. Unknown items should feed a tracked action list before approval.

References for Building an ISO 42005 AI Impact Assessment Process

If you want your ISO 42005 AI impact assessment process to stand up in practice, build it against well-known standards and governance sources.

Here are the references I would use.

ISO/IEC 42005, information to include in an AI system impact assessment
ISO/IEC 42001, AI management systems
ISO/IEC 23894, AI risk management
ISO/IEC 22989, AI concepts and terminology
ISO/IEC 23053, framework for AI systems using machine learning
ISO/IEC 27701, privacy information management
NIST AI Risk Management Framework 1.0
OECD AI Principles
UNESCO Recommendation on the Ethics of Artificial Intelligence
EU AI Act
GDPR and Data Protection Impact Assessment guidance
Sector-specific guidance for health, employment, financial services, public sector decision-making, and consumer protection

If your organization already uses model risk, privacy impact, or security review processes, map ISO 42005 fields into those workflows instead of creating a totally separate bureaucracy. That saves time and improves consistency.

Why ISO 42005 Becomes Useless When Treated as a Form-Filling Exercise

When teams treat ISO 42005 as paperwork, the AI impact assessment becomes a polished archive of half-truths. Current and planned uses blur together. Data quality gets overstated. Bias risks are softened. Misuse is ignored because it feels uncomfortable. Reviewers sign off on a document that looks complete while the actual system keeps changing underneath it.

When teams use ISO 42005 properly, the assessment becomes a living operating record. It tells you what the system does today, what it may do next, who can be affected, what evidence supports trust, where the risk sits, and what conditions must hold before launch or expansion. That changes governance from reactive to usable.

ISO 42005 works when each field forces a real answer, backed by evidence, owned by the right people, and revisited when the system changes.

If you reviewed one of your current AI impact assessments today, which section would show the biggest gap first: system scope, data quality, model evidence, deployment context, or foreseeable misuse?

Practical AI Assessments

Thu, 12 Mar 2026 00:00:00 +0000

The 9-Stage AI Assessment Framework That Answers Three Questions Every Project Must Face

Every AI project, regardless of industry, budget, or technology, must answer three questions at the right time. Can we build this? Are we ready to deploy it? Did it actually succeed?

Most organizations answer the first question with enthusiasm, rush past the second, and never systematically address the third. The result is predictable. Projects that were technically feasible but operationally unready get pushed into production. Systems that are deployed never get measured against the business case that justified them. And organizations accumulate AI systems they can’t confidently say are delivering value.

A structured AI assessment framework creates defined evaluation gates across the full project lifecycle. Nine assessments, grouped into three phases, ensure that every critical question gets asked at the point where the answer can still influence decisions. Skip an assessment and you’re making downstream commitments based on untested assumptions. Complete each one rigorously and you build a chain of evidence that supports every decision from concept through sustained operation.

This post walks through all nine assessments, explains what each one evaluates, and provides the practical guidance that determines whether these assessments produce real decisions or decorative documentation.

Phase 1: Can We Build This?

The first three assessments determine whether an AI project should proceed into development. They evaluate the problem, the technical viability, and the data foundation. Getting clear answers at this stage is the cheapest form of risk management available. Stopping a non-viable project during Phase 1 costs days of analysis time. Stopping it during development costs months of engineering effort.

These three assessments are interdependent. A strong use case with poor data readiness shouldn’t proceed. Strong data readiness without a clear use case produces a solution looking for a problem. Strong feasibility without either produces a technology demonstration with no business value.

All three assessments should be completed within the same evaluation window, typically two to four weeks, and reviewed together in a single go/no-go decision meeting.

Implementation tip: Assign ownership of each Phase 1 assessment to a different team member or function. The use case assessment should be owned by a business stakeholder who understands the problem. The feasibility analysis should be owned by a technical lead who can evaluate architecture, skills, and infrastructure honestly. The data readiness assessment should be owned by a data engineer who can verify data quality empirically, not theoretically. When one person or team owns all three, assessments tend to confirm the conclusion the owner has already reached. When different people with different perspectives own different assessments, the combined evaluation produces a more honest picture of project viability.

Assessment 1: Use Case Assessment

The use case assessment identifies the specific business problem the AI system will solve and quantifies the value of solving it. This is where most AI projects either build a strong foundation or begin accumulating the vague objectives that eventually undermine them.

Three activities define a thorough use case assessment.

Describe how users interact with AI to achieve a specific goal. This goes beyond describing what the AI system does. It describes the human workflow that the AI system fits into: who triggers the AI, what input they provide, what output they receive, what they do with that output, and how the AI-assisted workflow differs from the current process. A use case that describes only the AI component without describing the human workflow will produce a system that works in isolation and fails in practice.

Map current processes to quantify inefficiencies, expected value, and improvement areas. Before you can measure improvement, you need a documented baseline of how the process works today. Map each step in the current process, measure the time each step takes, identify where errors occur most frequently, and calculate the cost of the current approach. This map becomes the reference point against which all future performance measurements are compared.

Define measurable success metrics and align AI goals with user needs. Every use case should specify what success looks like in numbers: processing time targets, accuracy thresholds, cost reduction goals, and user satisfaction benchmarks. These metrics should reflect what users actually need, not what the technology can most easily deliver. A system that achieves 98% accuracy on a metric users don’t care about while achieving 70% accuracy on the metric they depend on has failed its use case regardless of the headline number.

What to document: The use case assessment should produce a single document containing: the problem statement, the current process map with baseline measurements, the proposed AI-assisted process, identified user roles and their interactions with the system, success metrics with numerical targets, and a preliminary estimate of business value.

Implementation tip: The process mapping step reveals hidden complexity that interviews and requirements documents miss. Documented processes and actual processes frequently diverge. Employees develop workarounds, skip steps that seem unnecessary, and add informal quality checks that aren’t in any procedure manual. Map the actual process by observing it, not by reading the documentation. The discrepancies between documented and actual processes often identify the real bottlenecks and the real opportunities for AI assistance, which may differ substantially from what the initial problem statement assumed.

The use case assessment identifies the specific business problem AI can solve. This is where the project gets anchored in an actual business need.

The responsible parties are the business owner, process owner, product lead, and AI governance or transformation lead. Legal, privacy, security, and compliance should be consulted where the use case touches regulated data or sensitive decisions.

The critical artifacts are the use case statement, user interaction description, current process map, pain point summary, value hypothesis, and success metrics. These should be clear enough that a reviewer can understand the business problem without needing a demo.

What to implement: Describe how users will interact with the AI system to achieve a specific goal. Map the current process to quantify inefficiencies, delays, rework, or quality problems. Identify the expected value and improvement areas. Define measurable success metrics and align the AI goal with user needs, not just management enthusiasm.

This assessment should answer a basic question. Is this a real business problem with a plausible AI role, or just a technology idea looking for a use case?

Implementation tip: Require one “current state” metric and one “target state” metric in the use case review. If there is no measurable gap, the value case is too weak.

Assessment 2: Feasibility Analysis

The feasibility analysis assesses whether the proposed AI solution can be built, deployed, and maintained within the organization’s technical, financial, and regulatory constraints. A viable use case that isn’t feasible should be shelved until constraints change, not forced into development.

Four evaluation areas define feasibility.

Evaluate tech stack, data, and skill availability. Does your current infrastructure support the proposed AI system’s compute, storage, and networking requirements? Does the team possess demonstrated experience with the required model architectures, development frameworks, and deployment patterns? Are gaps addressable within the project timeline through hiring, training, or partnerships? Honest answers to these questions prevent the common pattern of approving projects that require capabilities the organization doesn’t have and can’t acquire fast enough.

Estimate business ROI and strategic fit. Calculate projected return on investment using conservative assumptions. Include all costs: development, infrastructure, data preparation, training, deployment, and ongoing maintenance and monitoring. Compare projected value against projected cost over a 3-year horizon. Separately assess strategic fit: Does this project align with organizational AI strategy? Does it build capabilities that support future AI initiatives? Strategic value can justify projects with marginal ROI, but that tradeoff should be made explicitly, not by default.

Check regulatory and market readiness. Identify every regulation that applies to the proposed AI system in every geography where it will operate. Evaluate whether the system can meet compliance requirements. Assess whether the market context, including customer expectations, competitive dynamics, and industry norms, supports the proposed AI application. A technically feasible system that violates regulatory requirements isn’t feasible regardless of its other merits.

Gauge time and budget constraints. Compare the estimated development timeline against business deadlines. If the business need expires before the AI system can be deployed, the project isn’t feasible in its current form. Consider whether a reduced-scope version could deliver partial value within the available timeline.

Implementation tip: The most common feasibility analysis failure is evaluating each dimension independently and missing interactions between them. A project might be technically feasible (right skills, right infrastructure), financially feasible (positive ROI), and regulatorily feasible (compliant design) but still infeasible because the combination of regulatory compliance requirements and technical architecture decisions drives the cost above the ROI threshold. Evaluate feasibility dimensions in combination, not in isolation. Build a single feasibility summary that shows how constraints in one dimension affect assessments in others. This integrated view catches projects that pass each individual test but fail the combined evaluation.

Assessment 3: Data Readiness

The data readiness assessment determines whether the data required for the AI system exists, is accessible, is of sufficient quality, and can be used within governance and privacy requirements. Data readiness issues are the most common cause of AI project delays and failures, and the most frequently underassessed.

Four evaluation areas define data readiness.

Confirm data volume and quality. Does enough data exist to train the proposed model effectively? Is the data accurate, complete, and representative of the scenarios the AI system will encounter in production? Quality assessment should include specific measurements: missing value rates, error rates verified against ground truth samples, consistency of formats across records, and demographic or segment representation compared to target population distributions.

Check accessibility and format fit. Can the required data be accessed by the development team within security and governance requirements? Is the data in formats that the proposed model architecture can consume, or does significant transformation work stand between raw data and usable training sets? Data that exists but isn’t accessible, or that’s accessible but requires months of reformatting, changes the project timeline and cost significantly.

Assess labeling effort required. If the proposed approach uses supervised learning, does labeled data exist? If not, how much labeling effort is required, who will do it, and how long will it take? Data labeling is one of the most underestimated costs in AI project planning. A model that requires 50,000 labeled examples, at an average labeling rate of 200 examples per day per labeler, needs approximately 250 person-days of labeling effort before model training can begin.

Ensure data governance, provenance, and privacy compliance. Document the origin of each data source. Verify that the data can legally be used for the proposed purpose. Confirm that privacy requirements, including consent, anonymization, retention limits, and data subject rights, can be met. Identify whether a data protection impact assessment is required and, if so, complete it before development begins.

Implementation tip: Data readiness assessments that rely solely on metadata and documentation consistently overestimate readiness. The data catalog says the dataset contains 500,000 records. The actual dataset contains 500,000 rows, of which 80,000 are duplicates, 35,000 have critical fields missing, and 12,000 contain values outside valid ranges. After deduplication and quality filtering, the usable dataset is 373,000 records, which may or may not be sufficient. Always run a quantitative data profile as part of the readiness assessment: record counts after deduplication, null rates per field, value distribution analysis, and sample-based accuracy verification against source systems. The gap between documented data quality and measured data quality is almost always larger than expected.

Phase 2: Are We Ready to Deploy?

The next three assessments determine whether the AI system is ready for real-world operation. They progress from controlled validation (proof of concept) through limited real-world testing (pilot program) to full deployment preparation (production readiness).

Phase 2 assessments are inherently iterative. A proof of concept that reveals technical limitations feeds back into design changes. A pilot that surfaces user experience issues feeds back into interface refinement. A production readiness assessment that identifies security gaps feeds back into hardening work. This feedback is the point. Phase 2 exists to find problems while they’re still cheap to fix.

The transition between Phase 1 and Phase 2 should be a formal gate. Only projects that pass all three Phase 1 assessments should enter Phase 2. Projects that pass Phase 1 with conditions (such as “proceed if data labeling is completed by date X”) should have those conditions tracked and verified.

Assessment 4: Proof of Concept

The proof of concept tests core AI functionality with a minimal viable prototype using actual company data. It validates that the proposed approach works in practice, not just in theory.

Two evaluation priorities define the proof of concept.

Validate algorithm performance against defined metrics and baseline requirements. Using the success metrics defined in the use case assessment and the baseline measurements captured during process mapping, test whether the AI system meets, approaches, or falls short of targets. This validation must use actual company data, not public datasets or synthetic examples. Performance on generic data tells you whether the algorithm works in general. Performance on your data tells you whether it works for your problem.

Identify technical limitations and data quality issues before major investment. The proof of concept is designed to surface problems early. Does the model struggle with certain input categories? Does data quality degrade for specific subsets? Are inference times acceptable under realistic conditions? Are there edge cases that produce clearly wrong outputs? Document every limitation discovered. Each one represents a decision: fix it before proceeding, accept it as a known limitation, or determine that it disqualifies the approach entirely.

The proof of concept should be time-boxed. Two to four weeks is typical. The goal is to gather enough evidence to make a confident proceed/pivot/stop decision, not to build a polished system. Feature completeness is not the objective. Evidence-based confidence in the approach is the objective.

Implementation tip: Define proof of concept success criteria before building the prototype, and make those criteria the basis for the proceed decision. Without predefined criteria, proof of concept evaluations become subjective. The data science team sees promising results and wants to continue. The business stakeholder sees limitations and has concerns. Without agreed-upon criteria, the discussion becomes a negotiation rather than an evidence-based evaluation. Specify: “The proof of concept succeeds if the model achieves at least 80% of the target accuracy metric on a representative sample of production data, with inference times below 2x the production latency requirement.” Clear criteria produce clear decisions.

Assessment 5: Pilot Program

The pilot program deploys the AI solution with a limited user group to gather real-world performance data. It bridges the gap between controlled testing and full production by exposing the system to actual users, actual workflows, and actual operational conditions.

Four evaluation areas define the pilot.

Gather user feedback and pain points. The pilot is the first time real users interact with the system in their actual work context. Their feedback reveals usability issues, trust barriers, workflow friction, and output quality concerns that no amount of internal testing can replicate. Collect feedback through structured channels: in-application feedback mechanisms, weekly survey check-ins, and direct observation sessions where a team member watches users interact with the system.

Assess operational integration ease. Does the AI system fit into existing workflows without creating disruption? Do users need to switch between multiple applications? Does the system’s output arrive at the right point in the process and in a format users can act on? Integration friction that seems minor in a demo becomes a major adoption barrier in daily use.

Refine the implementation approach based on pilot findings. The pilot exists to generate the evidence needed to improve the system before full deployment. Plan for at least one refinement cycle between pilot completion and production rollout. Address the most common user complaints, fix the most impactful technical issues, and adjust the workflow integration based on observed usage patterns.

Estimate preliminary ROI and impact. Using pilot data, project the business impact of full deployment. If 20 pilot users processed 500 cases with 82% automation rate and 3.2x speed improvement, extrapolate what full deployment across 200 users would deliver. Compare this projection against the ROI estimate from the feasibility analysis. If the pilot suggests significantly lower returns than projected, reassess before committing to full deployment.

Implementation tip: Select pilot users deliberately, not randomly. Include enthusiastic early adopters (who will push the system’s capabilities and provide detailed feedback), skeptical experienced users (who will identify where the AI falls short of expert human judgment), and typical average users (who represent how the majority will interact with the system). A pilot group composed entirely of enthusiasts will produce optimistic results that don’t generalize. A pilot group composed entirely of skeptics will produce pessimistic results that discourage investment. A balanced group produces realistic data that supports honest deployment decisions.

Assessment 6: Production Readiness

The production readiness assessment validates that the AI system meets all technical, operational, and governance requirements for full deployment. This assessment should confirm that every requirement identified during feasibility analysis has been met or explicitly accepted as a known limitation with documented mitigation.

Four evaluation areas define production readiness.

Validate algorithm performance against defined metrics and baseline requirements at production scale. Proof of concept and pilot performance may not extrapolate to production volumes. Test the system at projected production load with realistic data volumes and concurrent user counts. Verify that performance metrics hold under stress conditions, not just average conditions.

Confirm that monitoring, alerting, and incident response mechanisms are operational. Before the system goes live, verify that production monitoring dashboards are functioning, automated alerts are configured for key performance thresholds, the incident response team knows their roles and procedures, and escalation paths are documented and tested.

Verify compliance and governance readiness. Confirm that all regulatory requirements identified during feasibility analysis have been addressed. Verify that required documentation, including model cards, impact assessments, and data processing records, is complete and current. Confirm that access controls, audit logging, and data handling procedures meet security and privacy standards.

Confirm operational support readiness. Verify that the support team knows how to triage AI-specific issues. Confirm that retraining procedures are documented and the team knows when and how to execute them. Verify that the rollback procedure, the process for reverting to the previous system if the AI deployment fails, has been tested and works.

Implementation tip: Run the production readiness assessment as a formal checklist review with sign-off from every responsible function: engineering, operations, security, compliance, and the business owner. Each function signs off on the criteria within their domain. The system enters production only when all functions have signed. This process prevents the common pattern where one function, usually engineering, declares the system “ready” based on technical criteria while operational, security, or compliance readiness gaps remain unaddressed. The sign-off requirement forces every function to evaluate readiness through their own lens and take accountability for their determination.

Phase 3: Did We Succeed?

The final three assessments evaluate whether the AI system delivers the value it promised. These assessments occur before launch (final validation), shortly after launch (performance review), and on an ongoing basis (value tracking).

Phase 3 is where most AI assessment frameworks end too early or never begin. Organizations invest heavily in determining whether they can build a system and whether they’re ready to deploy it, then stop measuring once it’s live. This creates a gap where systems operate without evidence of value, consuming resources indefinitely because nobody has the data to justify either continued investment or shutdown.

The transition from Phase 2 to Phase 3 should be seamless. Production readiness completion should automatically trigger the pre-launch validation timeline. Post-launch review should be scheduled before launch occurs. Value tracking cadence should be defined in the project plan, not established retroactively.

Assessment 7: Pre-Launch Validation

Pre-launch validation ensures the AI system is technically robust, secure, and optimized before going live in production. This assessment occurs after production readiness approval and before the system is made available to all users.

Four validation activities define this assessment.

Stress-test for scalability and speed. Push the system beyond projected peak loads to identify breaking points. If normal production load is 1,000 predictions per hour, test at 3,000 and 5,000 predictions per hour. Determine where performance degrades, where errors begin, and where the system fails entirely. This information enables capacity planning and defines operational boundaries.

Validate security and privacy controls. Conduct security testing specific to the AI system: test API endpoints for input validation and authentication, verify that model artifacts and training data are protected against unauthorized access, test for AI-specific vulnerabilities including prompt injection and data leakage, and confirm that privacy controls including data anonymization, consent verification, and retention enforcement function correctly.

Run performance and load tests. Beyond stress testing, conduct sustained performance testing that simulates realistic production usage patterns over extended periods, typically 24 to 72 hours. This testing reveals issues that short-duration tests miss: memory leaks that accumulate over hours, gradual performance degradation under sustained load, and resource contention with other systems sharing infrastructure.

Fix all bugs identified during validation before production launch. Every defect discovered during pre-launch validation must be classified, prioritized, and resolved or explicitly accepted before the system goes live. Critical and major bugs must be fixed. Minor bugs may be accepted with documented justification and a scheduled fix date. Do not launch with known critical defects.

Implementation tip: Pre-launch validation should include a “chaos test” that simulates the failure of key dependencies. What happens when the database connection drops? What happens when the model serving endpoint becomes unavailable? What happens when input data arrives in an unexpected format? Systems that handle dependency failures gracefully, by queuing requests, falling back to default behaviors, or alerting operators, are production-ready. Systems that crash or produce silently wrong outputs when a dependency fails are not. These failure scenarios are inevitable in production. Testing for them before launch ensures the system responds safely when they occur rather than creating incidents.

Assessment 8: Post-Launch Review

The post-launch review measures actual business outcomes against initial projections and success criteria. This assessment should occur at defined intervals after launch: 30 days, 90 days, and 6 months are typical checkpoints.

Three evaluation areas define the post-launch review.

Assess user adoption and satisfaction. Measure what percentage of target users are actively using the system, how frequently they use it, and how satisfied they are with its outputs. Compare adoption rates against the targets set during use case definition. If adoption is below target, investigate whether the gap is caused by usability issues, trust concerns, training gaps, or workflow friction. Low adoption negates all other performance metrics because a system nobody uses delivers no value regardless of its technical capabilities.

Monitor system performance, data drift, and model accuracy over time. Production performance should be measured against the same metrics used during proof of concept, pilot, and pre-launch validation. Track these metrics continuously, not just at review checkpoints. Watch for data drift, where the statistical properties of production data diverge from training data, causing model accuracy to degrade gradually. Establish automated alerts for accuracy drops, latency increases, and anomalous output distributions.

Identify operational lessons learned to refine future AI strategies. Every deployment teaches lessons that improve subsequent projects. Document what worked well, what didn’t work as expected, what risks materialized that weren’t anticipated, and what controls proved effective or ineffective. These lessons should be captured formally and shared with teams planning future AI initiatives.

Implementation tip: Schedule the 30-day post-launch review before the system launches, with a specific date, attendee list, and agenda template already established. Post-launch reviews that aren’t pre-scheduled get postponed indefinitely because the team moves on to the next project. The 30-day review is the most critical because it catches early problems while they’re still small and while the deployment team still has the context to diagnose them. By the 90-day review, team members may have rotated to other assignments and institutional memory about deployment decisions starts fading. The 30-day review window is the highest-leverage moment for identifying and correcting post-deployment issues.

Assessment 9: Value Tracking

Value tracking evaluates whether the AI system delivers the promised business value over time. This is an ongoing assessment, not a one-time review. It answers the question that ultimately determines the system’s fate: is this worth what we’re paying for it?

Three evaluation areas define value tracking.

Calculate true ROI and cost benefits. Compare actual costs (infrastructure, maintenance, support, model retraining, monitoring) against actual benefits (time saved, errors prevented, revenue generated, cost avoided). Use the same methodology that was used to project ROI during the feasibility analysis, applied to actual data rather than estimates. This comparison reveals whether the business case has held up, exceeded expectations, or fallen short.

Identify optimization opportunities. Production operation reveals inefficiencies and improvement opportunities that weren’t visible during development. Perhaps the model could be retrained on recent data to improve accuracy. Perhaps certain features could be simplified to reduce compute costs. Perhaps the system could be extended to adjacent use cases that share the same data and infrastructure. Value tracking should identify these opportunities and prioritize them based on expected incremental value.

Assess long-term business impact. Beyond direct ROI, evaluate the system’s broader effects on the organization. Has it changed how teams make decisions? Has it created new capabilities that enable other initiatives? Has it affected employee satisfaction or customer perception? These broader impacts are harder to quantify but often represent more durable value than direct cost savings.

Implementation tip: Value tracking should include a “continuation decision” at regular intervals, typically annually. At each interval, explicitly decide whether the system should continue operating, be enhanced, be maintained without further investment, or be retired. This decision requires comparing the ongoing cost of operation against the ongoing value delivered. Without a formal continuation decision, AI systems persist indefinitely by institutional inertia, consuming infrastructure costs, maintenance effort, and monitoring attention long after their value has diminished. The continuation decision forces the organization to treat every AI system as an investment that must justify its ongoing costs, not as a permanent fixture that operates until something breaks.

Implementation of AI Assessments

These principles apply across all nine assessments and all three phases.

Implementation tip on assessment documentation standards: Use a consistent template across all nine assessments. Each assessment document should include: assessment name, date, assessor, the system being assessed, the criteria evaluated, the findings for each criterion, the overall determination (pass/conditional pass/fail), any conditions or actions required, and the date of the next scheduled assessment. Consistent formatting enables comparison across assessments and across projects. When your tenth AI project uses the same assessment templates as your first, organizational learning compounds because patterns become visible across projects. Teams spot recurring failure modes, common data readiness issues, and consistent integration challenges that project-specific documentation would never reveal.

Implementation tip on assessment independence: The person or team conducting an assessment should not be the same person or team whose work is being assessed. Data scientists should not assess their own model’s production readiness. Project managers should not assess their own project’s feasibility. Business owners should not assess their own use case’s viability without external challenge. This principle creates tension that many organizations find uncomfortable. But self-assessment consistently produces optimistic evaluations because the assessor has a personal interest in the outcome. Independent assessment, whether from a dedicated governance function, a peer team, or an external party, produces more honest evaluations and catches issues that self-assessment misses.

Implementation tip on connecting assessments across phases: Each assessment should explicitly reference findings from previous assessments. The pilot program assessment should reference proof of concept findings and document whether identified limitations were addressed. The post-launch review should reference production readiness findings and verify that accepted risks are being monitored. The value tracking assessment should reference the ROI projections from the feasibility analysis and document variance. This cross-referencing creates a continuous evidence chain that supports governance, demonstrates due diligence, and prevents the common pattern where each assessment exists as an isolated document disconnected from the assessments before and after it.

Implementation tip on assessment cadence after Phase 3: Once all nine assessments are complete for a given AI system, the assessment cycle doesn’t end. Post-launch reviews should recur quarterly for the first year and semi-annually thereafter. Value tracking should recur annually at minimum. Any significant system change, such as model retraining, scope expansion, infrastructure migration, or regulatory change, should trigger reassessment of production readiness. Define this ongoing cadence in your AI governance framework so that it applies automatically to every deployed system rather than depending on individual project teams to remember.

Authoritative Frameworks

Your AI assessment framework should align with these established standards:

ISO/IEC 42001:2023, AI Management System (planning, evaluation, and improvement requirements)
ISO/IEC 5338, AI System Life Cycle Processes (stage-gate processes across AI development)
ISO/IEC 42005, AI Impact Assessment (assessment methodology and documentation)
ISO/IEC 23894:2023, AI Risk Management (risk assessment across lifecycle stages)
NIST AI Risk Management Framework, Map, Measure, and Manage functions
EU AI Act, Articles 9-15 for high-risk AI system assessment requirements
ISO/IEC 25010, Systems and Software Quality Requirements (quality criteria for system evaluation)
IEEE 2801-2022, Recommended Practice for Quality Management of Datasets (data readiness criteria)
ISO/IEC 27001:2022, Information Security Management (security assessment requirements)
PMBOK Guide stage-gate methodology adapted for AI project governance

If you conduct AI assessments as paperwork exercises, filling in templates to satisfy governance requirements without allowing findings to influence decisions, you will approve projects that should have been stopped, deploy systems that aren’t ready, and operate AI that may or may not be delivering value. Each unchecked assumption compounds risk. Each skipped assessment creates a blind spot. The assessments will exist in your document management system. The problems they should have caught will exist in your production environment.

When you treat each assessment as a genuine decision point, where findings lead to actions, where criteria determine outcomes, and where the answer “no, not yet” is valued as much as “yes, proceed,” you create a governance framework that protects both the organization and the people affected by its AI systems. The nine assessments answer three simple questions. Can we build this? Are we ready? Did it work? Organizations that answer these questions honestly, with evidence rather than optimism, build AI systems that earn the trust they require and deliver the value they promise.

An AI system that passes every assessment on evidence earns confidence. An AI system that skips assessments borrows confidence it may never repay.

About the Author

The frameworks, tools, and implementation guidance described in this article are part of the applied research and consulting work of Prof. Hernan Huwyler, MBA, CPA, CAIO. These materials are freely available for use, adaptation, and redistribution in your own AI governance, risk management, and compliance programs. If you find them valuable, the only ask is proper attribution. If you like the content, please like the article and share it.

Prof. Huwyler serves as AI GRC Consultancy Director, AI Risk Manager, and Quantitative Risk Lead, working with organizations across financial services, technology, healthcare, and public sector to build practical AI governance frameworks that survive contact with production systems and regulatory scrutiny. His work bridges the gap between academic AI risk theory and the operational controls that organizations actually need to deploy AI responsibly.

As a Speaker, Corporate Trainer, and Executive Advisor, he delivers programs on AI compliance, quantitative risk modeling, predictive risk automation, and AI audit readiness for executive leadership teams, boards, and technical practitioners. His teaching and advisory work spans IE Law School Executive Education and corporate engagements across Europe and globally.

Based in the Copenhagen Metropolitan Area, Denmark, with professional presence in Zurich and Geneva, Switzerland, Madrid, Spain, and Berlin, Germany, Prof. Huwyler works across jurisdictions where AI regulation is most active and where organizations face the most complex compliance landscapes.

His code repositories, risk model templates, and Python-based tools for AI governance are publicly available at . His ongoing writing on Governance, Risk Management and Compliance appears on his blogger website at (more than 500k views).

Connect with Prof. Huwyler on LinkedIn at to follow his latest work on AI risk assessment frameworks, compliance automation, model validation practices, and the evolving regulatory landscape for artificial intelligence.

If you’re building an AI governance program, standing up an AI risk function, preparing for EU AI Act compliance, or looking for practical implementation guidance that goes beyond policy documents, reach out. The best conversations start with a shared problem and a willingness to solve it with rigor.

The AI Loss Taxonomy Your Risk Assessments Are Missing

Thu, 12 Mar 2026 00:00:00 +0000

Incident Types and Direct Loss Categories That Define Real Exposure for AI Projects

Here is a question that reveals whether your AI risk program is mature or performative: Can you name the specific types of losses your AI systems could produce?

Not vague categories like “financial impact” or “reputational damage.” Specific, measurable loss types with clear boundaries between them. The difference between a regulatory fine and a legal compensation payment. The difference between algorithm remediation costs and data regeneration costs. The difference between customer churn and business disruption.

I asked this question to the risk committee of a healthcare AI company two years ago. The room went quiet. They had a risk register with 20 AI risks, each rated on a five-point scale for likelihood and impact. But when I asked “what kind of impact?” nobody could decompose their generic “high impact” ratings into the specific loss types that would actually appear on a financial statement or in a regulatory action.

That gap matters. You cannot quantify what you cannot classify. And you cannot prioritize controls, calculate return on investment, or purchase appropriate insurance if you cannot distinguish between the types of losses your AI systems might generate.

This post provides two complementary taxonomies. The first catalogs 37 distinct AI-related incident types across eight categories, each classified by whether it creates internal losses (relevant to risk assessments) or external losses (relevant to impact assessments) or both. The second catalogs 15 direct loss types across five domains that map to specific financial line items. Together, they give you the vocabulary and structure to make your AI risk assessments financially precise.

Why Generic Loss Categories Fail

Most AI risk assessments use three to five impact categories: financial, operational, reputational, regulatory, and strategic. These categories are so broad that they obscure more than they reveal.

When a risk assessment says an AI system has “high financial impact,” does that mean the organization will pay regulatory fines? Lose customers? Write off a failed project? Pay for emergency model remediation? All of these are “financial impact,” but they involve different stakeholders, different timescales, different control strategies, and different insurance coverage. Lumping them together makes the risk assessment useless for decision-making.

The same problem applies to incident classification. “AI bias” is not a single incident type. It manifests as biased outputs, unequal performance across groups, unfair discrimination, and lack of diversity in development teams. Each manifestation has different causes, different controls, and different loss profiles. Treating them as one incident type produces controls that are too generic to be effective.

The solution is granularity. Not complexity for its own sake, but sufficient decomposition to enable specific, actionable analysis. The taxonomies in this post provide that granularity.

Original implementation tip: When I first introduced a granular loss taxonomy to a financial services client, their initial reaction was that it added unnecessary complexity. They were managing 15 AI risks with five impact categories and felt that was sufficient. I asked them to take their highest-rated risk, “model produces biased outputs,” and trace it to specific financial consequences. They identified regulatory fines quickly. Then I asked about legal compensation payments to affected customers, algorithm remediation costs for retraining the model, control remediation costs for fixing governance gaps found during investigation, customer churn from affected populations, and reputation damage from media coverage. The total potential exposure across these six loss types was four times their original “high impact” estimate. Granularity did not add complexity. It revealed exposure they had been underestimating.

The incident taxonomy organizes 37 distinct incident types across eight categories. Each incident is classified as producing internal losses (considered in risk assessments), external losses (considered in impact assessments), or both.

This distinction matters for assessment methodology. Internal losses affect the organization directly through operational disruption, remediation costs, and control failures. External losses affect individuals, communities, or society through harm, discrimination, or rights violations. Many incidents produce both, requiring assessment from both perspectives.

Category 1: Cognitive Degradation

Three incident types address AI’s impact on human cognitive and decisional capacity.

Addiction and digital wellness (external only) occurs when AI systems contribute to addictive behaviors and negative impacts on digital wellness. Recommendation algorithms that maximize engagement metrics can create patterns of compulsive use. AI-driven content curation that prioritizes emotional arousal over informational value degrades the quality of users’ information environment. This is an external loss because the harm falls on users, not the organization, but regulatory attention to digital wellness is increasing, which creates secondary compliance exposure.

Loss of autonomy (internal and external) occurs when AI systems make decisions that diminish user control. This happens when automated decision-making replaces human judgment in contexts where individuals should retain meaningful choice. Internally, this manifests when employees lose the ability to exercise professional judgment because AI systems override their input. Externally, customers or citizens experience reduced agency in decisions affecting their lives, such as credit, employment, or healthcare.

Overreliance on AI (internal and external) occurs when users anthropomorphize, trust, or depend on AI systems beyond what the system’s capabilities warrant. Internally, decision-makers who treat model outputs as infallible stop applying critical judgment. Externally, users develop inappropriate emotional or material dependencies on AI systems, or form expectations the system cannot meet.

Original implementation tip: Overreliance on AI is the cognitive degradation incident type that creates the most immediate organizational risk, and it is almost never included in AI risk assessments. I worked with a lending organization where loan officers had become so accustomed to following the AI’s credit recommendations that they stopped reviewing the underlying data. When the model began producing anomalous scores due to a data pipeline issue, officers approved loans they would have questioned under manual review. The model was technically malfunctioning, but the actual failure was human. The loan officers had ceded their judgment to the system. The control is not technical. It is procedural: require documented human rationale for a sample of AI-supported decisions, and audit whether the rationale demonstrates independent judgment or simply restates the AI’s recommendation.

Category 2: Discrimination

Five incident types address unfair or unequal treatment produced by AI systems.

Bias in AI outputs (internal and external) occurs when models produce systematically biased predictions or recommendations. This is the broadest discrimination incident type and encompasses statistical bias embedded in model outputs that disadvantages specific groups.

Exposure to toxic content (external only) occurs when AI systems expose users to harmful, abusive, unsafe, or inappropriate content. Content recommendation systems, generative AI outputs, and AI-moderated platforms all carry this risk. The loss is borne by the affected users, but regulatory and reputational consequences flow back to the organization.

Lack of diversity in AI development (internal and external) occurs when homogeneous development teams build systems that reflect their own perspectives and blind spots. This is a root cause incident type. It does not produce harm directly but creates the conditions for bias, unfair discrimination, and unequal performance across groups.

Unequal performance across groups (internal and external) occurs when AI systems deliver different levels of accuracy, reliability, or quality for different user populations. A facial recognition system that works well for some skin tones and poorly for others. A speech recognition system that understands some accents and fails on others. The performance disparity itself is the incident, regardless of whether it results from intentional design or data limitations.

Unfair discrimination (internal and external) occurs when AI systems treat individuals or groups unfairly in consequential decisions. This goes beyond statistical bias in outputs to encompass the downstream effects: denied loans, rejected applications, misclassified individuals, or misrepresented groups.

Original implementation tip: The discrimination incident type that is hardest to detect is unequal performance across groups, because standard accuracy metrics can mask it completely. A model with 92% overall accuracy might have 97% accuracy for the majority population and 74% accuracy for a minority group. The aggregate metric looks fine. The disaggregated metrics reveal a serious problem. When I audit AI systems for discrimination risk, I require performance metrics disaggregated by every protected characteristic available in the data. If protected characteristics are not in the data, which is common, I require proxy analysis using correlated variables. The first time you disaggregate your model’s performance metrics, you will almost certainly find disparities you did not know existed.

Category 3: Disinformation Warfare

Three incident types address AI’s role in the information environment.

Disinformation and influence at scale (internal and external) occurs when AI systems enable large-scale manipulation of public opinion. This includes using AI to generate convincing fake content, automate social media manipulation, or conduct targeted influence campaigns. Internally, organizations face risk when their AI tools are misused for this purpose. Externally, society bears the cost of degraded public discourse.

False or misleading information (internal and external) occurs when AI systems generate or spread incorrect or deceptive information. This includes hallucination in large language models, inaccurate summaries, fabricated citations, and confidently stated falsehoods. Unlike deliberate disinformation, this often results from model limitations rather than malicious intent, but the impact on users who rely on the information is the same.

Pollution of information ecosystem (external only) occurs when AI-generated misinformation accumulates at sufficient scale to undermine shared reality. Filter bubbles, echo chambers, and the displacement of human-created content by AI-generated content of unknown reliability all contribute to this systemic effect.

Original implementation tip: False or misleading information is the disinformation incident type with the most immediate organizational liability, particularly for companies deploying generative AI in customer-facing applications. I advised a professional services firm that deployed a generative AI assistant to help clients navigate regulatory requirements. Within the first month, the assistant fabricated a regulation that did not exist and cited it confidently to a client. The client made a business decision based on the fabricated guidance. The firm’s liability exposure from that single incident exceeded the entire annual budget for their AI program. The control that would have prevented this is output verification: for any generative AI system providing factual information to external users, implement a verification layer that checks generated claims against an authoritative source before presenting them. This adds latency and cost. It also prevents lawsuits.

Category 4: Economic Displacement

Nine incident types address AI’s macroeconomic and organizational effects, making this the largest incident category.

Changes in employment patterns (internal and external) covers reduced quality of employment and increased exploitation of workers as AI reshapes job roles. Competitive dynamics (internal only) addresses the organizational risk from racing to deploy AI systems before they are safe, a pattern that increases the probability of releasing error-prone systems. Disruption of traditional industries (internal and external) covers economic instability when AI displaces established business models.

Economic and cultural devaluation of human effort (internal and external) occurs when AI-generated output reduces the perceived or actual value of human-created work. This affects pricing, employment, and professional identity across creative, analytical, and service industries.

Environmental harm (external only) covers the energy consumption, water usage, and carbon emissions from training and operating large AI systems. Governance failure (internal and external) occurs when regulatory frameworks cannot keep pace with AI development, creating gaps in oversight.

Increased inequality and decline in employment quality (internal and external) addresses the broader societal pattern of AI benefits accruing to capital owners while labor bears displacement costs. Job displacement and economic disruption (internal and external) covers direct job losses and industry disruption. Power centralization and unfair distribution of benefits (external only) addresses the concentration of AI capabilities and their economic benefits among a small number of organizations.

Original implementation tip: Of the nine economic displacement incident types, governance failure is the one that creates the most direct and immediate organizational risk, because it applies to every organization deploying AI, regardless of industry or scale. Governance failure is not just about regulators failing to keep pace with technology. It is also about your organization failing to build internal governance that compensates for regulatory gaps. I worked with a technology company that was deploying AI across 14 use cases with no centralized governance body, no standardized risk assessment process, and no consistent documentation requirements. Each team made independent decisions about model deployment, monitoring, and retirement. When the EU AI Act requirements became concrete, the company had no way to determine which of their systems qualified as high-risk, what documentation existed for each system, or who was accountable for compliance. They spent 11 months and significant resources building governance retroactively that would have cost a fraction to build proactively. If your organization deploys AI and does not have a governance framework, this is your highest-priority incident type to address. Not because governance failure is the most dramatic risk, but because its absence makes every other risk harder to manage.

Category 5: Exploitation

Two incident types address deliberate misuse of AI for harm.

AI weaponization (external only) covers the use of AI systems to develop cyber weapons or tools capable of mass harm. This is primarily a societal risk but creates organizational exposure when an organization’s AI tools or models are repurposed for weaponization by third parties.

Fraud, scams, and targeted manipulation (external only) covers the use of AI to conduct fraud, run scams, or manipulate individuals through personalized deception. AI-generated deepfake voices used in CEO fraud, AI-crafted phishing messages personalized from scraped data, and AI-assisted identity theft all fall here.

Category 6: Malicious Actors and Misinformation

Three incident types address AI-enabled attacks and synthetic media.

AI-powered phishing and social engineering (external only) covers the use of AI to create sophisticated, personalized phishing attacks and social engineering campaigns. AI enables attackers to generate convincing communications at scale, personalized to each target using publicly available information.

Use of AI for social engineering (external only) is a related but broader category covering all uses of AI to manipulate human behavior for unauthorized access or information disclosure.

Deepfakes and AI-generated content (external only) covers AI-generated synthetic media used to spread misinformation, impersonate individuals, or manipulate public opinion. This includes fake video, audio, images, and text that are increasingly difficult to distinguish from authentic content.

Category 7: Privacy Infringement

Five incident types address AI’s impact on personal data and privacy.

AI system security vulnerabilities and attacks (external only) covers exploitation of vulnerabilities in AI systems leading to unauthorized access, data breaches, or system manipulation causing unsafe outputs.

Collection of personal data (external only) covers AI systems that collect personal data without adequate consent. This includes passive data collection through AI-powered sensors, inference of personal characteristics from behavioral data, and collection that exceeds stated purposes.

Compromise of privacy (external only) occurs when AI systems memorize and leak sensitive personal data, or infer private information about individuals without consent. This is distinct from data breaches because the privacy compromise occurs through the model’s normal operation, not through a security failure.

Data breaches and unauthorized access (external only) covers traditional security incidents applied to AI contexts, including unauthorized access to training data, model weights, or inference logs containing personal information.

Surveillance and monitoring (external only) covers AI-powered surveillance that erodes trust and creates unease among individuals and communities. Facial recognition in public spaces, behavioral monitoring in workplaces, and predictive policing systems all carry this risk.

Original implementation tip: Compromise of privacy is the privacy incident type that is most specific to AI and least covered by traditional privacy controls. A large language model can memorize and reproduce fragments of its training data, including personal information, in its outputs. This is not a data breach in the traditional sense. No attacker exploited a vulnerability. The model simply learned its training data too well and reproduces it when prompted in certain ways. Traditional privacy controls focus on securing data at rest and in transit. They do not address data that is encoded in model weights. The control for this risk is differential privacy during training (adding noise to prevent memorization of individual data points) combined with output filtering that detects and blocks personal information in model responses. If your AI system was trained on data containing personal information, this incident type applies to you.

Category 8: Value Misalignment

Seven incident types address fundamental alignment between AI systems and human values.

AI possessing dangerous capabilities (external only) covers AI systems that develop or access capabilities increasing their potential for mass harm. This is an emerging and contested risk category, but it is increasingly relevant as AI systems become more capable.

AI pursuing its own goals in conflict with human goals (external only) covers AI systems acting contrary to the intentions of their designers or users. This ranges from reward hacking in reinforcement learning systems (achieving the stated objective through unintended means) to more speculative scenarios of advanced AI systems developing emergent goals.

AI system reliability and maintainability (internal and external) covers systems that are not reliable or maintainable, leading to errors and failures with significant consequences. This is particularly critical in applications requiring moral reasoning or operating in safety-critical environments.

Lack of accountability (internal and external) occurs when AI decision-making processes have no clear accountable party, leading to situations where harmful outcomes cannot be attributed, corrected, or prevented from recurring.

Lack of capability or robustness (internal and external) covers AI systems that fail under varying conditions. A model that works in testing but fails in production, a system that degrades when input distributions shift, or an application that produces errors under edge cases all represent this incident type.

Lack of explainability (internal and external) occurs when AI systems cannot explain their decisions to stakeholders who need to understand them, whether those stakeholders are regulators, affected individuals, or internal decision-makers.

Lack of transparency or interpretability (internal and external) covers broader challenges in understanding AI decision-making processes, leading to difficulty enforcing compliance, holding actors accountable, and identifying errors.

Original implementation tip: The value misalignment incident type I find most practically relevant for organizations today, the one that is neither speculative nor distant, is lack of accountability. Every AI failure I have investigated has had an accountability gap at its root. Not the absence of a responsible person in an organizational chart, but the absence of a person who knew they were responsible, had the authority to act, and had the information needed to act in time. The control is deceptively simple: for every production AI system, publish an accountability card that names the individual accountable for model performance, the individual accountable for data quality, the individual accountable for compliance, and the individual accountable for incident response. Post these accountability cards where the operations team can see them. Update them when people change roles. Test them by calling the named individuals during a tabletop exercise and verifying they know they are accountable and know what to do.

Part 2: Direct Loss Types

The incident taxonomy tells you what can happen. The direct loss taxonomy tells you what it costs. These 15 loss types map to specific financial line items that appear in budgets, financial statements, and insurance claims. They give your risk quantification the precision needed for credible Monte Carlo simulation and ROI analysis.

Five domains organize the 15 loss types.

Domain 1: Compliance Losses

Four loss types address the financial consequences of regulatory and legal exposure.

Regulatory fines cover penalties for violating AI regulations like the EU AI Act, privacy laws like GDPR, or sector-specific requirements. They also cover sanctions for data breaches, discriminatory outcomes, or copyright infringements produced by AI systems. These are typically the most visible AI losses because they are public, quantifiable, and reported.

Legal compensations cover settlement payments to affected parties for harm caused by AI malfunctions or decisions. This includes attorney fees and court costs for defending lawsuits from individuals or groups. Unlike regulatory fines, which are imposed by authorities, legal compensations arise from private litigation. They can be larger than fines and take longer to resolve.

Contractual credits cover service credits issued to customers when AI performance falls below guaranteed levels. Refunds and discounts applied for missed availability or accuracy commitments. These losses are often overlooked in risk assessments because they are managed by commercial teams, not risk teams, but they can be significant for organizations selling AI-powered services.

Legal response costs cover external legal counsel fees for investigating and responding to AI-related claims, as well as internal legal team costs for compliance reviews and regulatory correspondence. These costs are incurred regardless of whether the organization is ultimately found liable.

Control remediation covers costs to fix governance gaps identified in failed AI audits. This includes documentation, implementation, and certification expenses for new compliance controls and frameworks. This loss type often surprises organizations because it represents the cost of building governance they should have built proactively.

Original implementation tip: When estimating compliance losses for risk quantification, the most common error is using historical fine amounts as the basis for estimates. Historical data underestimates future exposure for two reasons. First, AI-specific regulations like the EU AI Act establish fine structures that far exceed previous penalties: up to 35 million euros or 7% of global annual turnover for certain violations. Second, regulatory enforcement of AI is in its early stages. The fines imposed in 2025 and 2026 will set precedents that do not yet exist in historical data. For AI compliance loss estimation, use the maximum penalty structures defined in applicable regulations as the upper bound of your range, not historical fine amounts. Your calibrated experts should estimate the probability of enforcement action and the likely penalty within the regulatory range, but the range itself should reflect the legal maximum, not past experience.

Domain 2: IT/Technical Losses

Three loss types address the costs of technical remediation and infrastructure.

Data regeneration covers costs to rebuild training datasets when data becomes corrupted, poisoned, or drifted beyond usability. This includes expenses for new data collection, labeling, cleaning, and validation. Data regeneration is expensive because high-quality training data is the most time-consuming and labor-intensive component of AI development. Rebuilding a corrupted training dataset can take months and cost more than the original data preparation.

Algorithm remediation covers engineering costs to retrain models that produce biased or inaccurate predictions. This includes compute resources for retraining, testing expenses for validation, and the data science team time required to diagnose the root cause, design the fix, and verify the corrected model’s performance. For complex models, remediation can require multiple retraining cycles.

Infrastructure overruns cover unexpected cloud computing and storage costs from inefficient AI resource usage. Emergency scaling expenses when systems face performance bottlenecks or capacity issues. AI workloads are computationally intensive and unpredictable. A model retraining job that runs longer than expected, a sudden spike in inference requests, or an unoptimized training pipeline can generate infrastructure costs that significantly exceed budget.

Original implementation tip: Algorithm remediation is the technical loss type most consistently underestimated in risk assessments. Teams estimate the compute cost of retraining but forget the human costs: the data science team time to diagnose the root cause (which can take weeks for complex model failures), the opportunity cost of pulling those data scientists off other projects, the testing and validation time for the remediated model, and the business cost of operating with a degraded model during the remediation period. When I help organizations estimate algorithm remediation costs, I use a formula that includes compute costs (typically the smallest component), data science team labor at fully loaded cost for the estimated remediation duration, lost productivity for the business processes that depend on the model during remediation, and any expedited procurement costs for additional compute resources or external expertise. The total is typically three to five times the compute cost alone.

Domain 3: Operational Losses

Five loss types address the business impact of AI failures on operations.

Decision errors cover financial losses from incorrect AI-driven business decisions made at scale. This includes costs of resource misallocation in operations, investments, or strategic planning based on flawed AI recommendations. The defining characteristic of decision error losses is scale. An AI system making thousands of decisions per day can accumulate significant losses before the error pattern is detected.

Operational inefficiency covers manual intervention costs when staff must correct or override AI outputs. Lost productivity from rework and staff time diverted to address AI failures. This loss type captures the ongoing drag on organizational performance that occurs when an AI system works poorly but not badly enough to take offline.

Development waste covers write-offs of failed AI projects that never reach production deployment. Sunk costs in licenses, development efforts, and procurement that yield no value. Industry estimates suggest that between 60% and 85% of AI projects fail to reach production. Each failed project represents development waste that should be included in the organization’s AI loss profile.

Business disruption covers revenue loss during downtime when AI-dependent processes stop functioning. Emergency replacement costs and lost transactions from service interruptions. This loss type is particularly relevant for organizations where AI systems sit in the critical path of revenue-generating processes.

Provider switching covers contract termination fees and cancellation penalties with current AI vendors. Migration costs, integration expenses, and negotiation time for new provider onboarding. This loss type is often triggered by other incidents, such as a vendor’s quality declining, a security breach at the vendor, or a strategic decision to reduce vendor dependency, but the switching costs themselves represent a distinct financial impact.

Original implementation tip: Development waste is the operational loss type with the highest aggregate financial impact across most organizations I work with, and it is almost never included in AI risk assessments because it is treated as a project management issue rather than a risk management issue. When I aggregate the fully loaded costs of failed AI projects across an organization, including salaries, compute resources, license fees, and opportunity costs, the total frequently exceeds the organization’s estimated exposure from all other AI risk scenarios combined. Include development waste in your loss taxonomy. Estimate it by multiplying the average fully loaded cost of an AI project by the historical failure rate. If you do not track your AI project failure rate, start. That number alone will change how your organization evaluates AI investments.

Domain 4: Revenue Losses

Two loss types address top-line financial impact.

Customer churn covers lost revenue from customers leaving after negative AI experiences or failures. Acquisition costs for replacing churned clients and margin erosion from retention efforts. This loss type has a compounding effect because the cost of acquiring a new customer is typically several times the cost of retaining an existing one.

Reputation damage covers brand value decline and crisis management costs following publicized AI incidents. Lost business opportunities and reduced market position from negative media coverage. This is the loss type most organizations acknowledge but least effectively quantify.

Original implementation tip: Reputation damage is the loss type I spent the most time helping organizations quantify, because it is the one where calibrated estimation is most valuable and most difficult. The approach that works is decomposition. Do not try to estimate “reputation damage” directly. Instead, estimate its measurable downstream effects. How many deals in the pipeline would be delayed or lost? (Estimate the pipeline value at risk.) How much would customer acquisition costs increase, and for how long? (Estimate the increment times the acquisition volume times the duration.) How much additional spending on PR and crisis management would be required? (Get a range from your communications team.) What revenue from existing contracts would be at risk of non-renewal? (Estimate the percentage of contracts with reputation-sensitive renewal decisions.) Add these components together. The total is more defensible than any direct estimate of “reputation damage” and more useful for risk quantification.

Connecting Incidents to Losses: The Traceability Requirement

The two taxonomies in this post are designed to work together. Each incident type produces one or more direct loss types. Mapping these connections creates the traceability needed for effective risk quantification.

Take a concrete example. The incident type “bias in AI outputs” (Discrimination category, internal and external) can produce the following direct losses: regulatory fines (if the bias violates the EU AI Act or fair lending laws), legal compensations (if affected individuals or groups file lawsuits), algorithm remediation (costs to diagnose and fix the biased model), control remediation (costs to build governance controls that should have prevented the bias), customer churn (if the affected population includes customers who leave), and reputation damage (if the bias becomes public).

Each of these loss types has a different magnitude, different timing, and different probability. Regulatory fines are large but require a regulatory investigation, which may take months. Legal compensations can exceed fines but require plaintiffs to organize and file. Algorithm remediation costs are incurred immediately but are typically the smallest component. Reputation damage may or may not materialize depending on media attention.

Without this incident-to-loss mapping, your risk quantification combines everything into a single “impact” number that is neither precise enough for Monte Carlo simulation nor useful enough for control investment decisions.

Original implementation tip: Build an incident-to-loss mapping matrix for every AI system in your portfolio. Down the left side, list every applicable incident type from this taxonomy. Across the top, list every applicable direct loss type. In each cell, indicate whether the incident could produce that loss type, and if so, provide a rough magnitude range. This matrix becomes the foundation for your FAIR-based risk quantification. When you estimate the impact component of a risk scenario, you are not estimating a single number. You are estimating the aggregate of all applicable loss types for the specific incident. This granularity dramatically improves the quality of Monte Carlo simulation inputs and the credibility of the outputs.

Internal Versus External: Why the Distinction Matters

The taxonomy classifies each incident type as producing internal losses, external losses, or both. This classification is not academic. It determines which assessment methodology applies.

Internal losses are costs borne by the organization. They are addressed through risk assessments that quantify exposure to the organization and inform control investment decisions. When you run a Monte Carlo simulation to calculate annualized loss exposure, you are modeling internal losses.

External losses are harms borne by individuals, communities, or society. They are addressed through impact assessments that evaluate potential harm to affected parties and inform responsible AI decisions. External losses may or may not create financial exposure for the organization (through fines, lawsuits, or reputation damage), but they matter independently because they represent real harm to real people.

Some incident types produce only internal losses. Competitive dynamics, for example, creates risk for the organization through unsafe AI deployment but does not directly harm external parties. Some produce only external losses. Surveillance and monitoring, for example, harms individuals and communities but may not create direct financial losses for the organization until it triggers regulatory action or public backlash.

Most incident types produce both. Bias in AI outputs, for example, creates internal losses through remediation costs and external losses through discriminatory harm to affected individuals.

Mature AI risk programs assess both dimensions for every applicable incident type. Immature programs assess only internal losses and are surprised when external harms generate regulatory, legal, or reputational consequences they did not anticipate.

Original implementation tip: The practical implication of the internal/external distinction is that you need two different assessment processes, and they should involve different people. Internal loss assessment is a financial exercise led by risk managers, using techniques like FAIR quantification and Monte Carlo simulation. External impact assessment is an ethical and societal exercise that should involve ethicists, affected community representatives, legal experts, and domain specialists, not just risk managers. I have seen organizations try to combine both assessments into a single process run by the risk team. The financial analysis crowds out the impact analysis every time. When a risk manager and an ethicist are in the same room, the conversation gravitates toward quantifiable financial exposure because that is what the risk manager knows how to discuss. Keep the assessments separate. Conduct them with different teams. Then combine the findings in a governance review where both perspectives inform the decision.

Cross-Cutting Implementation Tips

Four principles apply across both taxonomies.

Use the incident taxonomy to audit your risk register. Take every risk in your current AI risk register and map it to the incident types in this taxonomy. If a risk in your register maps to multiple incident types, decompose it. If incident types in this taxonomy have no corresponding risk in your register, you have a gap. This audit typically reveals that existing risk registers are too coarse and miss 40% to 60% of applicable incident types.

Original implementation tip: When I conduct this audit with organizations, the most common gaps are in the cognitive degradation and value misalignment categories. Risk teams are comfortable identifying bias, security, and privacy risks. They are much less comfortable identifying risks related to overreliance on AI, loss of autonomy, lack of explainability, or accountability gaps. These “softer” incident types are not soft in their consequences. Lack of accountability contributed to more AI incidents I have investigated than any specific technical failure. Include the full taxonomy in your audit, not just the categories that feel comfortable.

Use the direct loss taxonomy to improve your quantification. For every risk scenario you quantify, decompose the impact into the specific direct loss types that apply. Estimate each loss type separately using calibrated ranges. Then aggregate them for the total impact distribution. This produces more accurate estimates than a single “impact” range because subject matter experts can estimate specific loss types more credibly than they can estimate total impact.

Original implementation tip: When conducting estimation workshops, present loss types one at a time, not all at once. Ask experts to estimate regulatory fine exposure, then legal compensation exposure, then algorithm remediation costs, then customer churn impact, and so on. This prevents anchoring, where the first estimate influences all subsequent estimates, and produces wider, more honest ranges. The first time I tried this approach, the aggregate impact estimate was 2.3 times higher than the single “total impact” estimate the same experts had provided before decomposition. Decomposition reveals exposure that aggregation hides.

Update both taxonomies as the AI landscape evolves. New incident types emerge as AI capabilities expand. Generative AI created incident types like hallucination and prompt injection that did not exist five years ago. Autonomous agents will create new incident types that do not exist today. Review and update your taxonomies at least annually, and whenever a significant new AI capability is deployed within your organization.

Align your taxonomy with regulatory requirements. The EU AI Act, NIST AI RMF, ISO 42001, and ISO 23894 each reference specific types of AI-related harms and losses. Map your taxonomy to the categories used by the regulations that apply to your organization. This ensures that your risk assessments address every category a regulator will ask about and that your documentation uses consistent terminology.

Key References and Standards

This loss taxonomy draws from and aligns with the following authoritative frameworks.

ISO/IEC 42001:2023 for AI management system requirements covering governance and accountability for AI-related incidents and losses.

ISO/IEC 23894:2023 for AI risk management guidance, including classification of AI-specific risks and impacts.

ISO/IEC 27005:2022 for the information security risk management process, including loss event classification.

EU AI Act (Regulation 2024/1689) for the regulatory framework defining prohibited practices, high-risk requirements, and penalty structures for AI systems.

NIST AI RMF (AI 100-1) for the AI risk management lifecycle including harm categorization.

FAIR (Factor Analysis of Information Risk) for quantitative loss modeling taxonomy and methodology.

OECD AI Principles for the international framework addressing AI-related societal impacts.

UNESCO Recommendation on the Ethics of Artificial Intelligence for the broader ethical framework covering cognitive, social, and economic impacts.

MIT AI Risk Repository for the comprehensive academic catalog of AI risk incident types that informed several categories in this taxonomy.

Making These Taxonomies Operational

Organizations that file these taxonomies as reference documents will continue making the same mistakes. Their risk assessments will use generic impact categories that obscure actual exposure. Their incident response plans will not cover incident types they have not named. Their loss estimates will undercount by factors of two to five because they have not decomposed generic “impact” into specific loss types. When an AI incident occurs, they will discover that they cannot quantify their exposure because they never built the vocabulary to describe it precisely.

Organizations that operationalize these taxonomies will build risk assessments that distinguish between 37 distinct incident types and 15 direct loss categories. They will estimate exposure with the granularity needed for credible Monte Carlo simulation. They will map incidents to losses to controls, creating traceability that survives regulatory scrutiny. Their boards will understand AI risk in specific financial terms because the risk team can articulate exactly what kinds of costs would appear and on which financial lines.

The precision of your AI risk management cannot exceed the precision of your loss taxonomy. Name the losses specifically, or accept that your risk numbers are wrong.

Which loss types in this taxonomy are missing from your current AI risk assessments? Start with the ones you have never estimated. Those are where your biggest quantification gaps live.

Ai-Risk-Assessment |

Implementation Tips for ISO 42005 AI Impact Assessments

Why the ISO 42005 AI Impact Assessment Structure Matters

Understanding the Core Concept for ISO 42005 AI Impact Assessment Fields

The five field groups that matter most

1. Identity and governance fields

2. Scope and use fields

3. Data and model evidence fields

4. Deployment and affected-party fields

5. Benefits, harms, failures, and misuse fields

Stage 1: Complete the General Information Fields Like They Matter, Because They Do

Stage 2: Write a System Description That Exposes Real Scope

Stage 3: Treat Data Information and Quality as an Evidence Section, Not a Narrative Section

Stage 4: Use the Algorithms and Models Section to Show Decision-Quality Evidence

Stage 5: Ground the Assessment in Deployment Reality and Affected People

Stage 6: Write Benefits, Harms, Failures, and Misuse with Operational Honesty

Tips for ISO 42005 AI Impact Assessment

Tip 1: Do not let one team write the whole assessment alone

Tip 2: Use evidence links, not long pasted explanations

Tip 3: Reopen the assessment at known trigger points

Tip 4: Separate “unknown” from “not applicable”

References for Building an ISO 42005 AI Impact Assessment Process

Why ISO 42005 Becomes Useless When Treated as a Form-Filling Exercise

Practical AI Assessments

The 9-Stage AI Assessment Framework That Answers Three Questions Every Project Must Face

Phase 1: Can We Build This?

Assessment 1: Use Case Assessment

Assessment 2: Feasibility Analysis

Assessment 3: Data Readiness

Phase 2: Are We Ready to Deploy?

Assessment 4: Proof of Concept

Assessment 5: Pilot Program

Assessment 6: Production Readiness

Phase 3: Did We Succeed?

Assessment 7: Pre-Launch Validation

Assessment 8: Post-Launch Review

Assessment 9: Value Tracking

Implementation of AI Assessments

Authoritative Frameworks

About the Author

The AI Loss Taxonomy Your Risk Assessments Are Missing

Incident Types and Direct Loss Categories That Define Real Exposure for AI Projects

Why Generic Loss Categories Fail

Part 1: AI-Related Incident Types

Category 1: Cognitive Degradation

Category 2: Discrimination

Category 3: Disinformation Warfare

Category 4: Economic Displacement

Category 5: Exploitation

Category 6: Malicious Actors and Misinformation

Category 7: Privacy Infringement

Category 8: Value Misalignment

Part 2: Direct Loss Types

Domain 1: Compliance Losses

Domain 2: IT/Technical Losses

Domain 3: Operational Losses

Domain 4: Revenue Losses

Connecting Incidents to Losses: The Traceability Requirement

Internal Versus External: Why the Distinction Matters

Cross-Cutting Implementation Tips

Key References and Standards

Making These Taxonomies Operational