Technology & digital skills

AI engineering. Build it, then evaluate it.

Move from an AI demonstration to a workflow you can explain and test. A useful learning path combines programming, data handling, model use, evaluation and decisions about when a person must intervene.

This is a learning-path guide, not a confirmed course intake. Ask about current availability, syllabus, delivery format, entry requirements, fees and assessment before applying.

Ask about training availability

Find the right starting point.

You should be comfortable reading simple code, working with structured data and explaining a business task. If those foundations are new, begin with programming and data practice before taking on an application that uses external models.

Experience with a chat interface alone does not establish readiness to engineer an AI system. Ask how a programme teaches debugging, testing and handling an unsuccessful result.

Topics to agree in the syllabus.

Choose a coherent application rather than a tour of unrelated AI tools. The syllabus should connect how information reaches a model, what the model may do and how its output is checked.

Programming and data preparation: inputs, formats, errors and basic application structure.
Model interaction: prompts, structured responses and a clearly bounded task.
Retrieval: selecting suitable source material and checking that answers remain supported.
Tool use: explicit permissions, constrained actions and failure handling.
Evaluation: representative examples, expected behaviour and human review.
Operation: configuration, usage cost, latency and what happens when a dependency fails.

A practical project to discuss.

Build a small assistant that answers questions from a fictional internal handbook. Keep the source documents and questions synthetic, and show a source reference alongside each supported answer.

Include questions the handbook cannot answer. The assistant should make its limits clear rather than inventing policy. If you add a tool action, keep it in a test environment and require approval for any consequential change.

What the project should leave behind.

Ask for evidence that another person can reproduce and challenge. A polished conversation is only one part of the work.

A short problem statement and a diagram of the information flow.
A versioned implementation with clear setup instructions.
An evaluation set containing answerable, ambiguous and out-of-scope questions.
A record of observed failures and the changes made in response.
An explanation of permissions, data handling and human review.

How to assess progress.

Run the same evaluation examples before and after a change. Inspect whether the answer is supported, whether the system declines unsuitable requests and whether a reviewer can understand what happened.

A learner should explain why a chosen design fits the task, demonstrate a failure and describe the limits of the evidence. Do not treat a model benchmark or one successful demo as proof that the whole application is ready for production.

Start with your
actual requirement.

Tell us the work, people and outcome you have in mind. We’ll confirm current scope and availability before agreeing the next step.