About Course
Course Code: AI-A01 | School: School of Artificial Intelligence | Cluster: Level 5 — Advanced Systems & Innovation
Level: Advanced | Duration: 6 weeks · 24–30 learning hours | Language: English | Certificate: Professional Certificate (non-degree) | Format: Self-paced with AI support under human supervision
Overview
Most institutions adopt automation the wrong way round. They buy a tool, then look for something to automate with it, and end up with a fragile collection of scripts that nobody owns and nobody can audit. This course reverses that sequence. It teaches process analysis first, then automation design, then tool selection, on the argument that the hard part of automation is not building the workflow but deciding which work should exist at all.
The course is built for professionals who are not software engineers but who now have access to genuinely capable tools: workflow builders, low-code and no-code platforms, spreadsheet-native automation, document and form pipelines, and language-model steps embedded inside those pipelines. The technical content is concept-led and platform-agnostic. Learners work in at least one no-code orchestration environment, but the transferable skill being assessed is the ability to model a process, identify where automation creates value and where it creates risk, and specify a workflow precisely enough that someone else could build, test and maintain it.
Two positions are held throughout. Automation without process redesign usually accelerates a bad process. And an automated step containing a generative model inherits that model’s failure modes, which means every such step needs a defined verification point and a named human owner. The final project is assessed against both positions as much as against the working artefact.
Learning outcomes
On completion, a successful learner will be able to:
- Model an existing institutional process as an explicit sequence of tasks, decisions, actors, inputs and outputs, and identify its bottlenecks, rework loops and handoff failures.
- Distinguish tasks that should be eliminated, simplified, standardised or automated, and justify the choice by volume, variability, error cost and reversibility.
- Specify an automated workflow in a build specification containing trigger conditions, data schema, branching logic, error handling, retry behaviour and escalation paths.
- Build and test a working multi-step automation in a no-code orchestration platform, including one API integration and one language-model step.
- Design verification controls for generative steps, including thresholds, human checkpoints, output validation and logging sufficient for audit.
- Assess an automation proposal for governance exposure: data protection, access control, vendor dependency, cost drift and silent failure.
- Present an automation case to non-technical decision-makers with a defensible estimate of benefit, cost and residual risk.
Who this course is for
Operations, administration and planning staff who carry repetitive process load; analysts and researchers maintaining recurring data and reporting pipelines; managers accountable for process performance who must evaluate proposals rather than build them; and consultants advising institutions on AI adoption.
Prerequisites
Working competence with spreadsheets, including formulas and structured data. Familiarity with the material in AI-F01 and AI-F03. No programming background required, but learners should be prepared to read JSON and work with an API key. Access to at least one no-code orchestration platform is required; the Academy does not resell platform access.
Syllabus
Module 1 — What automation is actually for
Focus. Automation as a consequence of process design rather than a substitute for it. The distinction between task automation, process automation and decision support, and why conflating them produces most automation failures.
Lessons. 1.1 Three kinds of automation and why the difference matters. 1.2 Volume, variability, error cost, reversibility: a screening frame. 1.3 Four ways institutional automation fails. 1.4 What no-code changed and what it did not.
Core reading. Marlon Dumas, Marcello La Rosa, Jan Mendling & Hajo A. Reijers, Fundamentals of Business Process Management, 2nd edition (Berlin: Springer, 2018), chapters 1–2.
Deliverable. Process problem statement (one page) for a real recurring process in your institution.
Module 2 — Modelling the process before touching a tool
Focus. Producing an accurate as-is model. Task and decision notation, actors and handoffs, cycle time versus touch time, and the discipline of modelling what happens rather than what the policy says happens.
Lessons. 2.1 Notation that non-specialists can read. 2.2 Interviewing for what actually happens. 2.3 Measuring cycle time, touch time and rework. 2.4 Reading a model for waste.
Core reading. Dumas et al., Fundamentals of Business Process Management, chapters 3–4. Supplementary: Michael Hammer & James Champy, Reengineering the Corporation (New York: HarperBusiness, 1993).
Deliverable. As-is process model with three quantified pain points annotated.
Module 3 — Designing the to-be workflow
Focus. Redesign before automation. The eliminate–simplify–standardise–automate sequence, exception handling as a first-class design concern, and the build specification as the central professional artefact of the course.
Lessons. 3.1 Eliminate, simplify, standardise, then automate. 3.2 Designing for the exception, not the happy path. 3.3 Data schema, triggers and idempotency in plain language. 3.4 Anatomy of a build specification.
Core reading. Dumas et al., chapters 8–9. D. Sculley et al., “Hidden Technical Debt in Machine Learning Systems”, Advances in Neural Information Processing Systems 28 (2015).
Deliverable. Build specification precise enough for a third party to implement without further clarification.
Module 4 — Building it: orchestration, integration and language-model steps
Focus. Implementation in a no-code orchestration platform. Triggers, actions, branching, loops, error handling and retries. Connecting a service by API. Embedding a language-model step and constraining its output to a validated schema.
Lessons. 4.1 Triggers, actions and the shape of an orchestration graph. 4.2 Authentication, rate limits and reading an API response. 4.3 Language-model steps: prompt as interface, schema as contract. 4.4 Failure testing: empty, malformed, duplicate and adversarial inputs.
Core reading. Patrick Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, NeurIPS 33 (2020). Saleema Amershi et al., “Software Engineering for Machine Learning: A Case Study”, Proceedings of ICSE-SEIP (IEEE, 2019).
Deliverable. Working automation plus a test log recording what broke under the failure-test set.
Module 5 — Verification, control and the human in the loop
Focus. Making a generative step accountable. Where to place human checkpoints, how to log for audit, how to detect silent failure, and how to size the residual risk that remains after controls.
Lessons. 5.1 Hallucination and silent failure inside a pipeline. 5.2 Checkpoint placement as an economic decision. 5.3 Logging, traceability and reconstructability. 5.4 Monitoring, alerting and cost drift.
Core reading. Ziwei Ji et al., “Survey of Hallucination in Natural Language Generation”, ACM Computing Surveys 55, no. 12 (2023). NIST, AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1 (2023), MEASURE and MANAGE functions.
Deliverable. Control register mapping each control to a named failure mode.
Module 6 — Governance, cost and making the case
Focus. The institutional layer. Data protection and access control, vendor dependency and exit, total cost including maintenance, ownership and handover, and presenting the case to people who will be accountable for it.
Lessons. 6.1 Data protection, access control and least privilege. 6.2 Vendor dependency, portability and exit cost. 6.3 Total cost of ownership and who pays for maintenance. 6.4 Presenting the case: benefit, cost, residual risk.
Core reading. NIST AI RMF 1.0, GOVERN function. ISO/IEC 42001:2023 (clause structure; the full standard is a paid publication). OECD, Recommendation of the Council on Artificial Intelligence, OECD/LEGAL/0449 (2019, amended 2024).
Deliverable. Final project: specification, working automation, control register, governance annex and two-page decision brief.
Assessment
| Component | Weight |
| Module knowledge checks (6 × 2%) | 12% |
| As-is process model | 13% |
| Build specification | 25% |
| Working automation and test log | 25% |
| Control register and governance annex | 15% |
| Decision brief | 10% |
| Total | 100% |
Pass mark 70 per cent. All assessed components must be attempted. Every mark in this course is issued by a human assessor; no assessment outcome is generated automatically.
Rubric criteria
Each assessed artefact is marked against four criteria at four levels (distinction, pass with merit, pass, fail).
- Analytical accuracy: does the model or specification describe reality, and are claims supported by measurement or clearly labelled as estimate?
- Design judgement: is the automation boundary drawn where it creates value, with eliminate and simplify considered first?
- Robustness: are exceptions, failure modes and verification points identified and handled, including for generative steps?
- Communicability: could a competent colleague implement the specification, and could an accountable non-specialist act on the brief?
Reading list
Core. Marlon Dumas, Marcello La Rosa, Jan Mendling & Hajo A. Reijers, Fundamentals of Business Process Management, 2nd edition (Berlin: Springer, 2018).
Peer-reviewed. Patrick Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, NeurIPS 33 (2020). Ziwei Ji et al., “Survey of Hallucination in Natural Language Generation”, ACM Computing Surveys 55, no. 12 (2023). Saleema Amershi et al., “Software Engineering for Machine Learning: A Case Study”, ICSE-SEIP (IEEE, 2019). D. Sculley et al., “Hidden Technical Debt in Machine Learning Systems”, NeurIPS 28 (2015).
Standards and policy. NIST, AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1 (2023). ISO/IEC 42001:2023. OECD, Recommendation of the Council on Artificial Intelligence (2019, amended 2024). Regulation (EU) 2024/1689 (Artificial Intelligence Act), for learners with EU exposure.
Wider context. Thomas H. Davenport & Julia Kirby, Only Humans Need Apply (New York: Harper Business, 2016). Erik Brynjolfsson & Andrew McAfee, The Second Machine Age (New York: W. W. Norton, 2014). Michael Hammer & James Champy, Reengineering the Corporation (New York: HarperBusiness, 1993).
All items are published works identifiable by author, title and publisher. Learners obtain them through an institutional library or the publisher. The Academy does not distribute copyrighted texts.
Academic integrity and use of AI
Generative tools may be used in producing assessed work under three conditions. Use must be disclosed in a short statement appended to each submission, naming the tool and the task it performed. Any factual or technical claim originating from a generative tool must be verified against a citable source before it enters assessed work, and the verification must be evidenced. The analytical judgement in each artefact must be the learner’s own and must be defensible in a short follow-up. Learners must not connect institutional systems containing personal data to third-party platforms without their institution’s authorisation. Course exercises may be completed with synthetic data.
Instructor: pending owner confirmation. Pricing: pending owner approval. Reference list verified against publisher records; any later addition is marked for verification before publication.
Course Content
Module 0 — Start Here
-
Welcome and How This Course Works