“We lack AI skills” can conceal several different capability gaps. A professional-services firm buying an existing assistant needs different skills from a company training models or building an AI product. Treating every gap as a need for a data scientist can delay useful learning and leave governance unowned.
The answer is not that existing professionals can safely do everything after a prompting course. It is to identify the work, consequence and capability required at each layer, then decide what to develop, hire, partner for or avoid.
Start with tasks and accountability
Choose a real use case and map the people involved: practitioner, reviewer, service owner, data owner, technology team, security, privacy, risk, procurement and supplier. Identify which decisions remain human and which failures a competent person must recognise.
For each role, define:
- knowledge of the professional task;
- understanding of the system and its limits;
- ability to evaluate output;
- data and security responsibilities;
- exception and incident behaviour;
- authority to configure, approve or stop;
- evidence needed to remain competent as the service changes.
This prevents a generic “AI literacy” programme from being treated as permission to use any tool on any work.
Four capability layers
Layer 1: foundational literacy
People affected by an AI service need a practical understanding of what it does, what information may be used, where uncertainty appears and how to obtain help. They should know that fluent output can be wrong, incomplete or unsupported.
Literacy should cover the organisation’s policy, approved tools, confidentiality, personal data, intellectual property, professional obligations, bias, security, record keeping and incident reporting at a level relevant to the role.
One session may introduce these ideas. Competence needs reinforcement through scenarios, practice, supervision and updates.
Layer 2: task use and evaluation
Eligible users need to frame a task, provide appropriate context, inspect sources, test output and apply their professional judgement. Prompting is one small part of this layer.
Clear instructions, examples and structured output can improve results. They do not guarantee factuality or safe use. Users need evaluation criteria tied to the task: accuracy, completeness, tone, citation, confidentiality, accessibility or another quality standard.
Teach people when to abandon the tool. A long exchange can create misplaced commitment to a poor approach. Escalation and manual alternatives are part of skill.
Layer 3: configuration and service operation
A smaller group may configure permissions, retrieval sources, workflows, monitoring and vendor features inside supported boundaries. This can draw on product administration, integration, information governance and service-management skills.
Configuration is not inherently low risk. A permission error or retrieval change can affect many users. Use controlled environments, peer review, testing, release records and rollback.
Operators also monitor quality, adoption, incidents, supplier change and cost. The role needs time and authority, not merely enthusiasm.
Layer 4: engineering and specialist assurance
Custom applications, model adaptation, complex integration and advanced evaluation may require software, data, machine-learning, security, legal or domain specialists. The exact mix depends on the system.
A data scientist alone cannot cover product design, secure engineering, professional quality and governance. Build a multidisciplinary team and retain an accountable service owner.
External partners may provide rare depth. The firm still needs enough internal competence to set outcomes, judge evidence and manage dependency.
Do not assume value sits in the first two layers
Literacy and task use are widely relevant and can unlock practical benefits. The highest value for a particular firm may depend on workflow redesign, reliable information, integration or specialist engineering.
Avoid unsupported claims that most value always comes from prompting. A well-written prompt cannot correct an unsuitable use case, inaccessible knowledge or absent human review.
Measure outcomes from the task: quality, time, effort, client or colleague experience, error, rework and realised capacity. Tool usage and course completion are weak proxies.
Build learning into safe work
Classroom teaching can establish shared concepts. People develop usable capability by applying them to governed tasks with feedback.
Create a learning loop:
- choose an approved, bounded scenario;
- show an example and expected review;
- let participants practise on controlled information;
- compare output against a reference or expert judgement;
- discuss failure and uncertainty;
- record useful patterns and prohibited shortcuts;
- retest competence after material change.
Use realistic edge cases. A drafting exercise should include missing or conflicting information, not only an example designed to succeed.
Training data and examples must follow the same confidentiality and access rules as live work. Synthetic or sanitised material may be safer, provided it preserves the difficulty being taught.
Use champions with safeguards
Local champions can connect central policy with practice knowledge. Choose them for judgement, communication and credibility, not simply early enthusiasm.
Give the role defined time, approved access, support and boundaries. Champions can collect use cases, share learning, direct colleagues to policy and surface problems. They should not approve high-risk use or provide legal and security advice outside their competence.
Create a central forum that compares learning across teams and prevents several groups solving the same problem separately. Rotate or pair champions to reduce dependence on one person.
Recognition should reward useful evidence, including a negative result or caught error. Do not reward the largest number of prompts or automations.
Curate resources around the firm
A short, current resource set is more useful than an indiscriminate library. Include policy, approved tools, role-specific scenarios, evaluation checklists, escalation, examples and current external guidance from authoritative sources.
Give each item an owner and review date. Product interfaces, terms and rules change. A screenshot or instruction can become unsafe while remaining easy to find.
Short learning sessions can help teams share what they tried, what failed and what changed. Set a cadence that matches actual use. A fortnightly ritual with no new evidence becomes noise.
Preserve findings in a searchable record so learning survives staff movement and informal chat.
Create psychological safety and clear limits
People need to report errors and uncertain use without the immediate fear that disclosure itself will be punished. Leaders should model critical use, including examples they rejected or corrected.
Safety is compatible with accountability. Define approved experiments and prohibited uses. If somebody encounters a serious concern, protect clients and information first, then investigate the system and training fairly.
Avoid announcing that imperfection is acceptable for a fixed period without stating where experiments may occur. An internal draft can still contain confidential information or influence a professional decision.
Anonymous or confidential reporting routes may reveal shadow use. Use the evidence to improve policy and access, while retaining appropriate employment and professional processes for deliberate misconduct.
Decide whether to develop, hire or partner
Assess each capability by frequency, consequence, context, market availability and the need for independence.
Foundational learning usually needs internal ownership and may benefit from external legal, regulatory, security or educational expertise. Tool operation may be internal, managed or shared. Custom engineering may justify a partner, hire or neither if the use case lacks value.
Avoid universal rules based on a number of projects over two years. Compare total cost, continuity, supplier dependency, knowledge transfer and operating demand.
Distinction implements AI-related services and therefore has an interest in partner-led work. A capability decision should be open to the conclusion that the firm can use an existing product, should hire, needs specialist assurance or should not build the application.
Measure capability in behaviour
Evidence may include:
- correct classification of approved and prohibited use;
- ability to explain and apply review standards;
- detection of seeded errors or unsupported claims;
- safe handling of information and access;
- appropriate escalation and incident reporting;
- quality and rework in eligible tasks;
- reliance on support and change over time;
- successful operation and retirement of services.
Surveyed confidence can inform design and cannot certify competence. Certification from a short course should not create blanket authority.
Review skills when tools, suppliers, data, workflow or obligations change. Capability development is part of service operation.
The article on what using AI in your business means provides a foundation, and the guide to building momentum in risk-averse industries addresses wider change. The AI capability plan template can map roles to the four layers. A capability planning session should return task-specific needs, owners and development choices rather than a predetermined training programme.
You may not need a data scientist. You do need people who understand the work, can evaluate the system, govern its use and recognise when specialist depth is necessary.
