Iso-23053 |

Feasibility Assessment for AI Projects

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

How to Assess Data, Model Choice, and Integration Before You Build

Most AI projects do not fail because the idea was bad.

They fail because the feasibility work was weak. The team liked the use case, rushed into a proof of concept, then discovered the data was inconsistent, the model choice was poorly matched to the task, or the system could not fit into real workflows without adding friction and maintenance burden. By then, time and budget were already gone. A proper feasibility assessment prevents that.

This post focuses on three areas that decide whether an AI use case can actually work. Data, model choice, and integration and compatibility. If you get these wrong, even a promising business problem will turn into a fragile deployment. If you get them right, you give the project a real chance to succeed.

Understanding the Core Framework for AI Feasibility Assessment

Feasibility assessment is the step that tests whether the proposed AI solution can be delivered with the data, models, systems, controls, and people the organization actually has.

A lot of teams treat feasibility as a quick check. It is not. It is where you decide whether the use case is ready to proceed, needs redesign, or should stop. A strong feasibility review should answer three practical questions.

Do we have the right data?

Can we choose a model that fits the task and constraints?

Can the solution work inside our real environment?

Those three questions map directly to the structure of this post. Data. Model. Integration and compatibility.

Implementation tip: Do not assess these three areas in isolation. A strong model choice can fail because the data is weak. Good data can still fail because integration is poor. Feasibility only makes sense when the pieces are reviewed together.

Why Feasibility Work Often Breaks Down

The common failure points are predictable.

Teams assume they can “figure out the data later.” They select a model because it is popular instead of suitable. They build a pilot without understanding how users will actually consume the output. They ignore training needs. They overlook compute costs. They forget that long-term maintenance is part of feasibility, not an afterthought.

Another problem is optimism bias. Early AI use cases often get framed around what could work in the best scenario, not what can work under real constraints. That is where feasibility analysis adds discipline. It asks what data is available today, what resources exist now, what workflows can absorb change, and what support the organization can sustain over time.

Implementation tip: Write feasibility findings in plain language with explicit go, pause, or redesign recommendations. If the conclusion is vague, teams will interpret it as approval.

Stage 1: Assess Data Feasibility Before You Discuss Model Performance

Data quality shapes everything. If the data is inaccurate, incomplete, stale, inconsistent, or poorly aligned to the problem, the AI output will reflect those weaknesses no matter how strong the model looks in a demo.

The responsible parties are the business owner, data owner, data engineering team, data governance, AI or analytics leads, and where needed privacy, security, and compliance. The process owner should be involved because they understand how data is created and where it breaks down.

The critical artifacts are the data requirements inventory, source system map, data lineage view, quality assessment report, sampling review, and collection plan. These should show what data exists, what data is missing, what quality issues are known, and how those gaps affect the use case.

What to implement: Assess data requirements early in project planning. Identify the specific data needed to solve the problem. Determine where that data can be obtained and whether it is reliable, available, and permitted for the intended use. Check whether the data is accurate, relevant, and consistent. Review whether it represents the real-world scenarios the system is meant to model.

You should also test reliability over time. Data that looked good last quarter may not hold up under current operating conditions. Review for duplicates, formatting inconsistencies, missing values, broken labels, stale fields, and mismatched definitions across systems. Use cleaning and preprocessing to address issues, but document what was changed and what risk remains.

Coverage matters too. Verify that the data includes all relevant segments, categories, or use cases. Incomplete coverage often leads to biased or unstable outputs, especially when certain customer groups, geographies, product types, or document formats are underrepresented.

Implementation tip: Force the data review to answer one uncomfortable question clearly. “Which important cases are missing or poorly represented in the data?” That answer is often more useful than the average quality score.

Stage 2: Plan for Data Collection, Change, and Ongoing Validation

A data review is not a one-time event. Data changes. Source systems change. Business practices change. Relevance shifts.

The responsible parties are the data owner, data engineering, business process owners, and AI project lead. Privacy and security should review when new collection methods or new data sources are introduced.

The critical artifacts are the data collection strategy, source update schedule, quality monitoring plan, and validation rules. If the project depends on data that is still being collected or cleaned, that dependency should be visible.

What to implement: Plan ahead for data collection. Consider how availability, relevance, or source quality may change over time. Be ready to adjust collection strategy as the project evolves. Review and update data sources regularly to maintain relevance and accuracy. Test the model with real-world data to confirm performance across different scenarios, not just clean development samples.

If there is not enough real data to train or test the solution effectively, consider synthetic data carefully. Synthetic data can help expand coverage, support testing, or reduce certain privacy risks. Still, it should not be treated as a magic replacement for real-world signal. If the synthetic data fails to reflect actual edge cases, the project will still struggle.

Continuous monitoring and validation should be part of the design from the start. This means defining how data quality will be checked through the AI system lifecycle, who owns those checks, and what triggers remediation or retraining.

Implementation tip: Separate data sufficiency from data quality. You can have a large dataset that is still poor for the use case. Volume does not fix weak relevance.

Stage 3: Choose the Model Based on the Problem, Data, and Constraints

Once the data picture is clear, move to model feasibility. This is where teams often jump too quickly into a preferred technology.

The responsible parties are the AI lead, data scientists, ML engineers, enterprise architect, business owner, and governance or risk leads where model explainability or impact is important. Domain experts should review the intended model behavior against business reality.

The critical artifacts are the model suitability assessment, candidate model comparison, data-to-model fit analysis, compute estimate, and evaluation plan. These should explain why the selected model fits the task better than the alternatives.

What to implement: Assess the specific needs of the project before selecting a model. Consider the type of data, complexity of the problem, and desired outcomes. Match model strengths to the task. Classification, regression, ranking, retrieval, summarization, generation, anomaly detection, and forecasting all call for different approaches.

Also consider the size and quality of the dataset. Large and rich datasets may support more complex models. Smaller or noisier datasets may require simpler approaches. Check the availability of labeled data. Supervised learning depends on labeled data. Unsupervised or weakly supervised approaches may be more realistic when labels are limited.

Computational resources matter too. Some models require significant processing power, memory, and infrastructure support. That cost is part of feasibility. So is the ability to maintain the model over time.

Implementation tip: Do not ask which model is most advanced. Ask which model best solves the defined problem within your data, resource, and control constraints.

Stage 4: Balance Performance With Interpretability and Practicality

Model selection is not only about raw performance. It is also about explainability, maintainability, and operational fit.

The responsible parties are the same as in Stage 3, with stronger involvement from legal, compliance, product, or operations when the use case affects regulated decisions, customer communication, or sensitive workflows.

The critical artifacts are model test results, interpretability needs analysis, stakeholder explainability requirements, and tradeoff documentation. These help show why a model was chosen even if another option had slightly better benchmark performance.

What to implement: Prioritize interpretability when the use case requires clear explanations, strong auditability, or high trust from users and reviewers. Simpler models such as decision trees or linear models may be easier to justify in those contexts. More complex models may still be suitable, but only if the organization can explain, monitor, and govern them properly.

Test multiple models on a small scale before selecting one. Use realistic evaluation criteria tied to the use case, not generic benchmark enthusiasm. Continuously review and refine the choice as the project evolves and as new data becomes available.

Also check alignment with organizational strategy and technical capability. A model that your team cannot support, monitor, retrain, or explain is usually a weak fit even if it performs well in early tests.

Implementation tip: Write the model selection decision as a tradeoff statement. Include what the chosen model does well, what it does less well, and why that tradeoff is acceptable for the use case.

Stage 5: Assess Integration and Compatibility Before the Pilot Becomes a Surprise

This stage decides whether the AI system can fit into the current IT environment and operational workflow without causing friction or duplication.

The responsible parties are enterprise architecture, IT, product, operations, business process owners, AI specialists, security, and support teams. End-user representatives should be consulted because they understand practical workflow constraints better than architecture diagrams do.

The critical artifacts are the integration architecture, workflow impact assessment, dependency map, training needs analysis, maintenance plan, and rollout approach. These should show what existing tools the AI system must connect to and what changes will be required.

What to implement: Assess how the AI system will integrate with current platforms, tools, and workflows. Evaluate operational impact through IT and workflow assessments. Make sure AI predictions or outputs can be applied consistently in the right context. If the output arrives too late, in the wrong system, or without enough context, the technical success will not matter.

Review employee training needs too. A usable AI system still fails if the people who rely on it do not know when to trust it, when to override it, or how to escalate issues. Long-term maintenance and support belong here as well. If the AI solution introduces a separate support burden with no clear owner, that is a feasibility warning.

Phased rollouts and pilots are valuable because they reveal integration issues before full deployment. They also help surface system bottlenecks, data compatibility issues, and workflow disruption early enough to fix them.

Implementation tip: Ask a simple workflow question during integration review. “What does the user have to stop doing, start doing, or do differently because of this AI system?” If the answer is unclear, the workflow design is not ready.

Stage 6: Anticipate Compatibility Issues and Build an Adjustment Path

Even well-planned integrations hit friction. The point is not to expect perfection. The point is to prepare for manageable adjustment.

The responsible parties are IT, AI specialists, business operations, product, and support. Governance, security, and privacy should be informed where changes affect control boundaries or data handling.

The critical artifacts are the issue log, communication plan, rollout feedback loop, and remediation path. These make integration problems visible and manageable.

What to implement: Anticipate data compatibility issues, system bottlenecks, workflow conflicts, and support demands. Build communication channels between IT, AI teams, and end-users so issues can be resolved quickly. Keep pilot reviews structured enough to capture root causes, not just user frustration.

This stage is also where teams should decide whether the AI system should be fully embedded into existing tools or exposed through a separate interface. Embedding can improve adoption. It can also complicate support and control if the surrounding systems are not ready.

Implementation tip: During the pilot, track not only whether the AI works, but whether the surrounding systems and people can absorb it without workarounds. Workarounds are early warnings.

Cross-Cutting Implementation Tips for AI Feasibility Assessment

These tips apply across data, model, and integration work.

Tip 1: Start with the hardest constraint, not the most exciting feature

Feasibility gets clearer when you test the toughest condition first. That may be data coverage, compute capacity, explainability, or workflow fit.

Implementation tip: In the first feasibility review, ask which constraint is most likely to block the project. Focus there before investing heavily elsewhere.

Tip 2: Use real operational scenarios early

A lot of feasibility work looks better in controlled testing than in real operations.

Implementation tip: Build test cases from actual documents, actual user flows, actual edge cases, and actual system dependencies. Synthetic scenarios have a place, but they should not dominate.

Tip 3: Keep revisiting feasibility as the project evolves

Feasibility is not only a front-end checkpoint. It changes when data, scope, users, or systems change.

Implementation tip: Reopen feasibility review after major data changes, model changes, workflow redesigns, or expansion to new user groups.

Tip 4: Document why a use case is feasible, not only that it is

A yes or no answer is too thin for later review.

Implementation tip: Record the evidence behind the feasibility decision, the assumptions being made, and the conditions that must remain true for the decision to stay valid.

References for AI Feasibility Assessments

If you want a strong front-end process for deciding whether an AI use case can work, anchor it in recognized governance and technical standards.

Here are the references I would use.

ISO/IEC 42001, AI management systems
ISO/IEC 42005, information to include in an AI impact assessment
ISO/IEC 23894, AI risk management
NIST AI Risk Management Framework 1.0
ISO/IEC 23053, framework for AI systems using machine learning
ISO/IEC 27701, privacy information management
Internal architecture review, data governance, and project intake standards
Operational readiness and change management frameworks for system rollout

If your organization already has enterprise architecture review, data governance councils, security review, and PMO stage gates, connect feasibility assessment into those forums. That creates stronger evidence and reduces duplication.

Why Feasibility Assessment Fails When Treated as a Quick Checkbox

When teams treat feasibility as a quick checkbox, they validate the idea instead of testing the constraints. They overestimate data quality, select models too early, underestimate integration friction, and treat maintenance as somebody else’s future problem. The result is predictable. The pilot works just well enough to create momentum, then struggles once it meets real systems and real users.

When teams treat feasibility as a serious operating step, they test whether the data is trustworthy, whether the model fits the task, whether the organization can support it, and whether the workflow can absorb it. That leads to better decisions early and fewer expensive surprises later.

A strong AI project survives because feasibility was challenged honestly before the build began.

If you reviewed your current AI pipeline today, which feasibility weakness would likely surface first: weak data quality, poor model fit, underestimated compute cost, or integration friction with existing workflows?

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.

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?