Business Analysis for AI Solutions

AI differs from traditional IT because its behaviour is probabilistic, not deterministic. As a result, for many experienced IT professionals, understanding AI is a challenge. 

Implementation is usually handled by AI engineers and data scientists. Without clear business input, teams drift toward demos rather than robust, governable solutions.

It takes years to understand AI at the level of AI developers. However, this course can teach you enough AI to define necessary requirements and guardrails.

Like all training delivered by Business Abstraction, this course is very practical and focused on your current needs. Contact us to organise on-site training or to enquire about public training. 

Who should attend

• Business Analysts

• Business Process Analysts

• Business Architects

• Project Managers

• Prompt Engineers and other AI-specific roles

• Data Analysts, unless covered by more specialised training

• Solution Architects, unless covered by more specialised training

• All other project members who are not covered by more specialised or technical training. 

Deliverables

• A use case register (top 3–10 candidates)

• For the top 1–2 use cases: a quality definition and acceptance criteria

• A lightweight evaluation rubric (how you will judge outputs)

• A refactored process blueprint for 1 priority use case

• A control checklist (human review, logging, change control, escalation)

• A “pilot → production” gating plan (what evidence is required)

Training schedule

While a course is always customised to your needs, the following is used as the starting point for customisation:

Half-day 1: Overview of Generative AI 

Attendance of everyone is expected, including management/executives

• Understanding modern AI

• Generative AI revolution

• Lab: running AI prompts

• Lab: experimenting with AI 

• Lab: problem solving with Generative AI

Half-day 2: Understanding other types of applications of AI 

• Demonstration of other types of AI:

  • Predictive AI

  • Image AI

  • Time Series AI

  • Graph AI

• Integrating Generative AI with other types of AI

• Understanding Agentic AI

Half-day 3: Defining AI Use Cases

• Use case anatomy (what “good” looks like)

  • user / decision / workflow context (where the output is used)

  • required level of correctness and allowable error

  • latency, volume, cost constraints

  • data sensitivity and privacy/security constraints

  • fallback behaviour (what happens when the AI is wrong/uncertain)

• Define “quality” for this use case

  • accuracy / correctness (or task success rate)

  • groundedness / traceability (can we justify outputs?)

  • robustness (edge cases, adversarial prompts, ambiguous inputs)

  • bias/fairness considerations (where relevant)

  • auditability / recordkeeping requirements

• Evaluation plan at “project-definition level”

  • what to measure, how to sample, what “pass” means

  • “gold set” examples and expected outputs

  • human review rubric (what reviewers look for)

  • minimum monitoring signals after go‑live

• Risk framing 

  • statistical risks (variance, drift, non-determinism)

  • operational risks (hallucinations, automation bias, misuse)

  • governance risks (unreviewed changes, missing evidence)

  • security risks (data leakage, prompt injection if using RAG/tools)

• Lab: Use Case Quality Canvas (2–3 candidate use cases). Participants fill a one‑page template per use case, then score with a simple matrix:

  • value

  • feasibility

  • risk

  • evidence burden

Half-day 4: AI-focused Process Refactoring

Design the “human + AI” process so you can operate it safely: control points, responsibilities, and evidence.

• Abstracting Processes

  • identifying primary objectives

  • identifying alternative outcomes

  • identifying dependencies

• Process mapping: before → after

  • identify where AI adds value vs where it adds risk

  • define “human-in-the-loop” points (review, approval, escalation)

  • define failure modes and fallbacks (what happens when AI output is low confidence)

• Controls and guardrails

  • input controls (what can be fed into the system)

  • output controls (review rules, restricted actions, disclaimers)

  • prompt/model change control (who can change what, and how it’s approved)

  • recordkeeping: what must be logged for audit/reconstruction

• Operating model (who owns what)

  • roles: business owner, product owner, platform/ops, risk/compliance, security

  • a simple RACI for: approvals, incidents, monitoring, change requests

• From pilot to production (go/no‑go gates)

  • what evidence is required before expansion

  • what monitoring is required after go‑live

  • what triggers rollback / incident response

• Lab: Refactor one real process using the top use case from Half‑day 3

  • a “to‑be” process map with control points

  • a one‑page operating model / RACI

  • a go/no‑go checklist (minimum evidence pack)

Contact us to organise on-site training or to enquire about public training.