Why should AI learning be role-specific?

Organisation-wide AI training is an efficient way to establish shared language, policies and responsible-use expectations. Its examples can become less useful when everyone is asked to practise the same generic task.

An underwriter, a product manager and a technical leader may use the same AI tool, but their purposes, evidence and responsibilities differ. Useful learning must prepare them for those differences.

Role-specific learning extends a common foundation into recognisable professional decisions. It does not require a separate course for every job title.

AI capability is expressed through a role

Practical AI skills gain meaning through work. “Evaluate an AI output” sounds universal, but evaluation depends on the intended use.

An underwriter reviewing a risk summary may need traceability to source documents, correct interpretation of insurance terms and clear referral of missing information. A product manager analysing discovery notes must preserve minority perspectives and distinguish evidence from generated hypotheses. A technical leader reviewing AI-assisted code needs to consider security, maintainability, test evidence and ownership.

The shared skill is critical evaluation. The quality criteria, consequences and required domain knowledge are role-specific. Learning should make both levels visible.

Role context also shapes the decision not to use AI. A task may be inappropriate because the available tool cannot handle the data, because the evidence cannot be checked or because a professional must make the judgement directly.

One foundation is useful but incomplete

A common foundation helps an organisation communicate consistently. It can cover basic concepts, approved tools, information handling, known limitations, accountability and habits such as checking sources. Cross-functional learning can also reveal different perspectives and improve handoffs.

The foundation becomes incomplete when it assumes that understanding a general example enables application everywhere. Learners may know the rules but not recognise how they affect their own work. They may practise drafting generic text when their role requires assessing evidence, managing uncertainty or making a controlled referral.

This is not an argument for discarding broad learning. The design challenge is to keep what should be shared and add differentiation where the work changes materially.

Build pathways from work, not job titles

Start by analysing the work rather than the organisation chart. For each audience, identify:

• Recurring tasks where AI may be useful.
• Decisions the person makes or influences.
• Source information and data restrictions.
• Standards a usable output must meet.
• Common errors and uncertainty.
• Consequences if the result is wrong.
• Human review and escalation requirements.

These elements define a capability profile and suggest realistic scenarios. Role experts should help create and review them because they understand the language, exceptions and professional standards that a generic learning designer may miss.

Different job titles can share a pathway when these elements are similar. The same title may need more than one level when responsibilities differ. Grouping should follow meaningful capability needs, not provide superficial personalisation.

Balance consistency with meaningful difference

A practical programme can use a shared core followed by pathway modules. The core establishes common rules and evaluation habits. Pathways let learners apply them to relevant tasks, evidence and decision points.

Create a separate pathway only when the answer changes materially. If two groups need the same behaviour and differ only in the names used in an example, one adaptable scenario may be enough. If the decision rights, risks or quality criteria differ, targeted practice is justified.

Maintain consistency through common design standards. Every pathway should protect professional judgement, use approved information, include output checking and clarify accountability. Subject-matter reviewers can validate the professional context without turning the module into technical procedure training.

Role-based design also needs maintenance. Workflows and tools change, so scenarios should be reviewed with the people doing the work. The aim is a relevant learning experience that helps professionals augment their expertise, not a catalogue that mirrors every role in the organisation.

Example

An organisation gives product managers and technical leaders the same foundation on safe AI use, data boundaries and critical evaluation.

Product managers then practise analysing fictional discovery evidence. They challenge themes that lack source support and separate customer evidence from AI-generated hypotheses. Technical leaders review a proposed AI-assisted code change, its tests and an architecture decision record. They identify assurance gaps and decide what needs specialist review.

Both groups use common responsible-use principles. Their practice differs because their decisions, evidence standards and accountabilities differ.

FAQs

• Does every role need a separate AI course?

  No. Use a common foundation where concepts, policies and evaluation habits are shared. Create a pathway when tasks, decisions, evidence standards, risks or oversight needs change materially. Similar roles can often share scenarios with small adaptations.

• How do you identify role-specific AI capabilities?

  Analyse recurring work, decision points, source information, quality criteria, common errors, consequences and required human review. Involve people who perform or oversee the work so the capability profile reflects genuine professional practice.

• Can cross-functional teams still learn together?

  Yes. Shared sessions can establish common principles and expose different perspectives at handoffs. Role-specific exercises can then deepen application. A combined scenario may also work when each participant has a distinct decision or review responsibility.