vaayaa Inclusive Education
Technical risk assessment

AI Solution Development Risk Assessment: Objectives, Data, Testing and Safe Deployment Controls

A worked example of how a team building an AI-enabled solution identifies, scores and controls the risks to objectives, data, testing, people, suppliers and users, from scope creep to harmful outputs.

Updated November 2026 8 hazards assessed Review every 6 months Highest risk: Critical to Medium
See the AI Solution Development course

Executive summary

This assessment shows how a team building an AI-enabled solution can find, rate and control the risks that matter most to its objectives, data, users and people. Eight hazards were chosen because they are plausible in everyday development work. Harmful or incorrect outputs reaching users is the highest inherent risk, because the impact on people can be serious even when the likelihood is moderate. Poor data quality, unclear objectives and weak security also score High before controls. After existing and added controls, most hazards fall to Medium or Low, but output safety stays at Medium because human review cannot catch every error. The first actions are a written use case with success and stop criteria, a data source register, a staged test and release gate, and a tested rollback. Each action has a named owner and a timeframe. The team reviews the register on the stated cycle and before each release.

Focus area
AI solution design, development and deployment
Setting
Product or service team building an AI-enabled solution for internal or external business users
Method
Five by five likelihood and impact risk register

Scope

This assessment covers a development team building an AI-enabled solution, from problem definition and data preparation through model building, testing, release and early operation. It looks at risks to objectives, data, people, suppliers, users and legal duties. The sector, jurisdiction, data types and deployment platform are not specified and are treated as assumptions for teaching. Scores illustrate method and do not describe any real product.

Context

The team has a product owner, a lead data scientist, two machine learning engineers, a software developer, a data protection lead and a quality assurance lead. Training data comes from internal records and a licensed third-party dataset. A hosted model service and a cloud platform provide compute and storage. The solution will assist business users with recommendations, and staff will review outputs before acting. Each hazard is scored before controls to show its natural level, then again after existing and added controls.

Objectives, assets and stakeholders

The objective is to deliver a useful solution that performs as specified, respects the privacy and rights of the people it affects, stays within budget and can be supported after launch. The assets in scope are the problem definition and success criteria, training and evaluation data, model artifacts and code, the development and hosting environments, the product roadmap and the trust of users and sponsors. Stakeholders include the product owner, engineers and data scientists, the data protection lead, quality testers, business users, customers whose data is used, suppliers of models and cloud services, and the executive sponsor. Every hazard has one owner role. The product owner keeps the register current, reports to the sponsor each month and shares the release decision with the quality assurance lead.

Risk matrix: before and after controls

Each cell shows hazard numbers placed by likelihood and impact. Compare the two grids to see how controls move each hazard.

Before controls

Inherent risk

Risk before controls: rows are likelihood from almost certain to rare, columns are impact from insignificant to catastrophic. Cells list hazard numbers.
1
Insignificant		 2
Minor		 3
Moderate		 4
Major		 5
Catastrophic
5 Almost certain
4 Likely Likelihood 4, impact 4, score 16, high: H01 H02 Likelihood 4, impact 5, score 20, critical: H03
3 Possible Likelihood 3, impact 3, score 9, medium: H04 H06 H08 Likelihood 3, impact 4, score 12, high: H07 Likelihood 3, impact 5, score 15, high: H05
2 Unlikely
1 Rare

After controls

Residual risk

Risk after controls: rows are likelihood from almost certain to rare, columns are impact from insignificant to catastrophic. Cells list hazard numbers.
1
Insignificant		 2
Minor		 3
Moderate		 4
Major		 5
Catastrophic
5 Almost certain
4 Likely
3 Possible Likelihood 3, impact 2, score 6, medium: H02
2 Unlikely Likelihood 2, impact 2, score 4, low: H04 H08 Likelihood 2, impact 3, score 6, medium: H01 H06 H07 Likelihood 2, impact 4, score 8, medium: H03 H05
1 Rare
  • Low 1 to 4
  • Medium 5 to 9
  • High 10 to 16
  • Critical 17 to 25

Hazard register

A summary first, then the detail for each hazard.

Summary of hazards with scores before and after controls
No.HazardBeforeAfterOwner
H01 Unclear objectives and scope creep 16 High 6 Medium Product owner
H02 Poor data quality and biased training data 16 High 6 Medium Lead data scientist
H03 Harmful or incorrect model outputs reach users 20 Critical 8 Medium Quality assurance lead
H04 Skills gaps and key person dependency 9 Medium 4 Low Engineering manager
H05 Data exposure and security weaknesses in development 15 High 8 Medium Information security lead
H06 Dependence on a single model or cloud supplier 9 Medium 6 Medium Procurement lead
H07 Legal, ethical and reputational harm from unclear use 12 High 6 Medium Data protection lead
H08 Budget overrun from compute and rework costs 9 Medium 4 Low Finance business partner
H01

Unclear objectives and scope creep

Strategic Before 16 After 6

Success criteria are vague, requirements keep changing, and the team builds a solution that does not meet the real business need or spends budget on features nobody asked for.

Who or what is affected: Sponsor, product owner, users and delivery team

Causes

Unclear business need, pressure to show quick results and features added without review.

Consequences

Wasted budget, a product nobody uses and loss of sponsor confidence.

Existing controls

  • A project charter names the sponsor and the budget.
  • Sprint reviews show progress to the product owner.

Control gaps

Changes are agreed informally and the charter is not updated.

Additional controls

  • Prevent: Write a use case with measurable success and stop criteria, signed by the sponsor.
  • Detect: Review scope changes each sprint against the charter and log every change.
Likelihood 4 x impact 4 before; 2 x 3 after Owner: Product owner Target: Within 30 days Early warning: Scope changes logged in a sprint without a matching update to the charter.
H02

Poor data quality and biased training data

Technology and data Before 16 After 6

Training data is incomplete, outdated, mislabeled or unrepresentative of the people the solution will affect, so the model learns errors and treats some groups unfairly.

Who or what is affected: Users, customers in the data and the delivery team

Causes

Historic records reflect past decisions, labels are inconsistent and sampling is convenient rather than representative.

Consequences

Poor recommendations, unfair outcomes, rework and complaints.

Existing controls

  • Data is cleaned by the data scientist before training.
  • A sample of records is checked by hand each month.

Control gaps

Results are not reported by user group and label quality is not measured.

Additional controls

  • Prevent: Keep a data source register with owner, purpose, quality checks and known gaps for each dataset.
  • Detect: Test performance separately for each user group and report gaps before release.
Likelihood 4 x impact 4 before; 3 x 2 after Owner: Lead data scientist Target: Within 45 days Early warning: Gap between accuracy for two user groups above the agreed limit.
H03

Harmful or incorrect model outputs reach users

Safety Before 20 After 8

The solution gives confident but wrong or unsafe answers, and staff or customers act on them before anyone notices, causing financial, physical or personal harm.

Who or what is affected: Business users, customers and people named in outputs

Causes

Narrow test cases, rare edge inputs, overconfidence in fluent answers and pressure to release on time.

Consequences

Wrong decisions, injury or financial loss, complaints and regulator attention.

Existing controls

  • Testers run a fixed set of test cases before each release.
  • Users see a notice that outputs must be checked before use.

Control gaps

Test cases do not cover rare or adversarial inputs and nobody owns post release monitoring.

Additional controls

  • Prevent: Require a human sign-off step for any output that affects payments, access, health or employment.
  • Respond: Provide a one click report button and a route to pause the feature for affected users.
Likelihood 4 x impact 5 before; 2 x 4 after Owner: Quality assurance lead Target: Within 30 days Early warning: Rising count of user reports marked as wrong or unsafe in a week.
H04

Skills gaps and key person dependency

People Before 9 After 4

Only one or two people understand the data pipeline, model design or hosting setup, and skills in responsible design and secure coding are thin, so progress stalls or errors go unnoticed when someone leaves.

Who or what is affected: Delivery team, sponsor and future maintainers

Causes

Specialist hiring is slow, knowledge sits in individual heads and training is not budgeted.

Consequences

Delays, quality errors and higher cost to replace people.

Existing controls

  • Design decisions are recorded in a shared wiki.
  • Pair work is used for core pipeline changes.

Control gaps

Handover plans are not tested and training needs are not reviewed.

Additional controls

  • Prevent: Build a skills plan with cross training and documented runbooks for each core component.
  • Recover: Keep a named backup owner for each component and test the handover once a quarter.
Likelihood 3 x impact 3 before; 2 x 2 after Owner: Engineering manager Target: Within 60 days Early warning: A core component where only one person is able to make changes.
H05

Data exposure and security weaknesses in development

Technology and data Before 15 After 8

Personal or confidential training data is copied to laptops, shared storage or third-party tools, or model artifacts are exposed, so data is leaked or stolen.

Who or what is affected: Data subjects, customers, staff and the organization

Causes

Convenient copies, weak access reviews and tools that send data to outside services.

Consequences

Privacy harm, legal action, loss of trust and possible shutdown of the project.

Existing controls

  • Project storage requires sign in with multi-factor checks.
  • Training data is kept in one approved environment.

Control gaps

Copies made for experiments are not tracked or deleted.

Additional controls

  • Prevent: Mask or remove personal fields before data leaves the approved environment and limit access by role.
  • Detect: Log and alert on large downloads or sharing of datasets outside the project.
Likelihood 3 x impact 5 before; 2 x 4 after Owner: Information security lead Target: Within 30 days Early warning: Datasets found in storage locations outside the approved environment.
H06

Dependence on a single model or cloud supplier

Supplier Before 9 After 6

The solution relies on one hosted model service or cloud platform whose prices, terms, availability or data handling change, leaving the team unable to run or move the solution.

Who or what is affected: Product owner, customers and finance team

Causes

A single source chosen for speed, proprietary interfaces and changes to vendor pricing.

Consequences

Outage, sudden cost increase, a supplier data handling breach and forced redesign.

Existing controls

  • The supplier contract includes a service level for uptime.
  • Usage is reviewed with the supplier each quarter.

Control gaps

Exit steps are not written down and terms on data reuse are not checked.

Additional controls

  • Respond: Keep a documented fallback model and an exit plan with data export steps.
  • Recover: Test moving the solution to a second provider once a year.
Likelihood 3 x impact 3 before; 2 x 3 after Owner: Procurement lead Target: Within 60 days Early warning: Supplier notice of a price, term or service change within the contract period.
H07

Legal, ethical and reputational harm from unclear use

Legal and compliance Before 12 After 6

Training data is used without clear rights, users are not told when an automated system affects them, or accountability for decisions is unclear, leading to complaints, claims or loss of public trust.

Who or what is affected: Customers, staff, data subjects and sponsor

Causes

Fast timelines, unclear rules for automated decisions and vague ownership across teams.

Consequences

Claims, fines in some jurisdictions, forced withdrawal and reputational damage.

Existing controls

  • Data use terms are reviewed by the data protection lead before training starts.
  • A fairness statement is published in plain language.

Control gaps

Rights checks are done once at project start and not repeated at each release.

Additional controls

  • Prevent: Complete an ethics and rights check at each gate, including the consent basis and named human accountability.
  • Recover: Keep a public correction route and a process to remove affected data and retrain.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Data protection lead Target: Within 45 days Early warning: Complaints about automated decisions or unclear use of personal data.
H08

Budget overrun from compute and rework costs

Financial Before 9 After 4

Training runs, hosting and rework cost more than planned because experiments repeat without limits and release dates slip, so the budget runs out before the solution is stable.

Who or what is affected: Sponsor, finance team and delivery team

Causes

Repeated experiments, unplanned scope and pricing that is hard to estimate.

Consequences

Cancelled features, a stopped project and pressure to cut testing.

Existing controls

  • Monthly cloud spend is reported to the sponsor.
  • Training jobs need a named owner who approves each run.

Control gaps

Experiment costs are not tracked separately from production costs.

Additional controls

  • Prevent: Set a compute budget per sprint with an approval step for large runs.
  • Detect: Compare forecast and actual spend each week and flag variances above 10%.
Likelihood 3 x impact 3 before; 2 x 2 after Owner: Finance business partner Target: Within 30 days Early warning: Weekly spend running above forecast by more than 10%.

Rating method and evaluation

Each hazard is rated on two five-point scales. Likelihood runs from Rare to Almost certain, and impact runs from Insignificant to Catastrophic. Multiplying the two gives a score from 1 to 25, placed in one of four bands: Low from 1 to 4, Medium from 5 to 9, High from 10 to 16 and Critical from 17 to 25. Impact considers harm to people and data subjects, cost, delay, legal exposure, service continuity and reputation. Inherent risk is the score before any controls, judged as if the team did only normal practice. Residual risk is the score after existing and added controls, and it must never be higher than the inherent score. Anything still High needs sponsor attention and a dated plan, Medium needs routine controls with a named owner, and Low is accepted and watched. Scores are challenged in a short review where the data scientist, engineer, tester and data protection lead each explain their view, and a score changes only with written evidence such as test results or incident records. Any hazard whose indicator reaches its threshold is re-scored at once.

Likelihood, impact and rating bands

Likelihood

  • 5 Almost certain: Expected to happen in most circumstances.
  • 4 Likely: Will probably happen in many circumstances.
  • 3 Possible: Could happen at some time.
  • 2 Unlikely: Not expected, but it could happen.
  • 1 Rare: Only in exceptional circumstances.

Impact

  • 1 Insignificant: No lasting effect. Handled within routine work.
  • 2 Minor: Small effect that is quickly corrected.
  • 3 Moderate: Noticeable effect that needs managed effort to correct.
  • 4 Major: Serious effect on people, delivery or reputation.
  • 5 Catastrophic: Severe or lasting effect that threatens the whole activity.

Bands (likelihood x impact)

  • Low (1 to 4): Accept and monitor.
  • Medium (5 to 9): Manage with routine controls.
  • High (10 to 16): Senior attention and a treatment plan.
  • Critical (17 to 25): Act first. Do not proceed until reduced.

Monitoring, escalation and review

Review this assessment every 6 months, and sooner when an indicator below reaches its threshold.

Early-warning indicators and escalation thresholds
Indicator to watchEscalate when
Share of test cases where output is rated harmful or wrong by the quality assurance lead.Escalate to the product owner when above the agreed threshold, and pause release until the sponsor is informed.
Data sources added to training without a completed register entry.Escalate to the data protection lead at once, and hold the dataset until the entry is complete.
Model accuracy on the holdout set falling below the agreed floor after a change.Escalate to the engineering manager at once, and to the product owner if not restored within one week.
Cloud and model service spend above the monthly budget by more than 10%.Escalate to the finance business partner when reached, and to the executive sponsor if it persists for two months.
Open access rights for leavers or for staff outside the project team.Escalate to the information security lead the same day, and remove the right within one working day.

Contingency arrangements

If a serious event occurs, such as harmful outputs reaching users, a data exposure or a supplier outage, the product owner pauses the affected feature and the release gate is closed. The engineering manager switches users to the previous tested version or a manual process. The data protection lead assesses any personal data involved and advises on notifications required in the relevant jurisdiction, with specialist legal advice. Affected users receive a clear, plain message about what to do next. The root cause is recorded, and the register is updated before the feature returns.

Prioritized action plan

  1. Write a use case with success and stop criteria before further build work, owner product owner, within 30 days.
  2. Create a data source register with use terms, bias checks and retention rules, owner data protection lead, within 45 days.
  3. Introduce a staged test and release gate with human sign-off for any output affecting people, owner quality assurance lead, within 45 days.
  4. Set up a tested rollback and an access review for model, data and hosting environments, owner engineering manager, within 30 days.
  5. Review supplier terms for the model service, data handling and exit options, owner procurement lead, within 60 days.

Conclusion

Dependable AI solutions rest on steady habits: a clear use case, documented data sources, staged testing with stop criteria, human review where harm is possible, controlled access and a tested rollback. The highest inherent scores sit with harmful outputs, unclear objectives and data quality, and each has actions that reduce residual risk. Treat the register as a living record, review it on the stated cycle and before each release, and seek qualified advice for any real legal, privacy or security question.

Assumptions and limitations

Assumptions

  • Jurisdiction and sector are not specified, so legal duties are described in general terms only.
  • Training data includes personal information and is held under written use terms agreed with its owners.
  • The solution is reviewed by a human before any output affects a customer, employee or payment.
  • The hosted model service and cloud platform are chosen by the team and used under a standard contract.

Limitations

  • The scores are examples for learning and do not describe any real product or organization.
  • AI, privacy, security and employment rules differ by country and change over time, so specialist legal and security review is needed.
  • This is educational content and does not replace a formal site-specific assessment or licensed advice.

Related frameworks to study

  • Risk register with likelihood and impact scoring
  • Hierarchy of controls
  • Three lines model of risk ownership

Technical Risk Assessment

China, India, United States, Indonesia, Pakistan, Nigeria, Brazil, Bangladesh, Russia, Japan, Mexico, Philippines, Vietnam, Egypt, Turkey, Germany, United Kingdom, France, Italy, Canada, South Korea, Australia, Spain.

For Learning Reference Only: This assessment demonstrates how risk assessment principles are applied in a practical setting, providing a useful reference for learning and understanding. Actual assessments may be adapted to suit specific site conditions and circumstances.

Keep learning

Study the subject behind this assessment.

AI Solution Development course Read the best practices for this course

More Technical risk assessments

Hourly Active: 39,047 Learners