What Should Nontechnical Workers Learn Before Advanced AI Skills?

What does OECD Skills in the AI age actually tell a nontechnical worker?

If you have limited time, should you strengthen foundations, learn to use AI tools, or start coding? The answer in OECD’s *Skills in the AI age: Executive summary* is a set of relevant skill areas, not a universal order: identify what capability the work you want to do requires, then learn toward that need. The OECD supports broad AI literacy and names foundational, digital and complementary skills, but it does not prescribe what every nontechnical worker must learn first or test whether one sequence works better than another.

So “before” is the decision this article examines, not an instruction to attribute to the OECD. Broad AI literacy concerns understanding and using AI in work; specialist development concerns deeper technical work such as building or implementing systems. A sequence can be useful for a particular task or destination, but it is an editorial decision rule grounded in that context, not a curriculum proved by the report.

That distinction matters when a worker is choosing among learning options. A person who needs to apply an approved tool to a familiar task may have a different immediate learning need from someone whose target work involves integrating systems or developing models. The report’s categories help make those needs visible, but they do not rank courses, define a common starting level or show that coding must come after—or before—every other capability. The relevant starting point depends on the output the worker wants to produce and the capability currently missing. Prior knowledge, role requirements and available time shape that choice.

Sources: Skills in the AI age: Executive summary

Why does the report begin with capabilities beyond AI?

Literacy, numeracy and scientific knowledge matter because work with AI still involves understanding the task, reading the information behind an answer and judging what its quantities or assumptions mean. OECD’s *Skills in the AI age: Executive summary* includes these foundations among the capabilities relevant in the AI age. They help a worker learn unfamiliar methods and make sense of evidence when tools or processes change; they are not a claim that every occupation needs the same level of each capability or that all learning should begin with a general education course.

Consider a hypothetical knowledge-work task: a team asks for a short explanation of whether a proposed change reduced customer waiting time. An AI system might produce a clear summary of a spreadsheet. To decide whether that summary answers the question, a worker needs to understand what the recorded values represent, how waiting time was counted, and whether the comparison covers equivalent periods. Numeracy helps interpret the difference and its scale; reading comprehension helps distinguish the question from the generated wording; scientific reasoning helps ask whether the comparison supports the conclusion or leaves another explanation open. This is an illustration of the role those capabilities can play, not an OECD case or reported result.

The example shows why fluent output and sound interpretation are different achievements. A polished explanation can still rest on an ambiguous measure, an incomplete comparison or an assumption that does not fit the work. More advanced AI terminology would not by itself resolve those issues: the worker must understand enough about the task and evidence to notice what the answer means and what it leaves unsettled. In that sense, foundations support both using new tools and learning more specialized material, because they let the learner connect technical language to quantities, claims and real work rather than memorizing terms in isolation.

That does not make a broad “foundations first” course the right next step for everyone. Many workers already use reading, quantitative reasoning or scientific thinking in their jobs and may have no relevant gap to repair. The practical question is narrower: does the task the worker wants to perform reveal a specific difficulty in understanding the evidence, quantities or assumptions? If not, repeating material already mastered could spend scarce learning time without improving the work. If yes, the useful learning target is the demonstrated gap at the level the task demands, not a checklist item taken on faith.

The OECD’s categories therefore help name a capability, while the worker’s task determines whether it needs attention. A person reviewing operational comparisons may need to revisit how a rate or denominator works; someone interpreting technical reports may need practice separating a result from the conclusion drawn from it. These are task-linked possibilities, not prescriptions supplied by the report. The point is to preserve the distinction between possessing a foundation and needing to study it again: prior experience may already provide the capability, while a changed task can reveal a new application or a narrow area that deserves practice.

The practical value can also appear when the work changes slightly. Suppose the same team later compares waiting times across two service locations. The interface and report format may be familiar, but the worker still has to understand whether the locations use the same definition, whether the groups are comparable, and whether a difference in totals reflects different volumes. Reading and quantitative reasoning help make those questions answerable; scientific reasoning supports distinguishing an observed pattern from a causal explanation. These capabilities do not guarantee a correct conclusion, but they let the worker identify what would need clarification before relying on one.

This is why foundational knowledge is not simply a preliminary stage to be completed once and left behind. Its relevance depends on the demands of a task: a worker may be fluent in routine reporting yet need to strengthen a particular concept when responsible for interpreting a new measure or unfamiliar evidence. The alternative is not necessarily a long course. A short practice exercise using the actual kind of information the worker must interpret, feedback from a knowledgeable colleague, or review of a relevant concept may reveal whether the gap is real and what depth is needed. Such steps are practical options inferred from the role of the capabilities, not interventions evaluated by the OECD report.

Conversely, a worker who already understands the information and assumptions may benefit more from practice with a new application or workflow than from repeating basic material. The report’s grouping is useful for recognizing that AI-related work draws on more than technical operation; it cannot determine an individual’s proficiency from a job title or decide the correct course. The worker’s existing experience is evidence too: recurring tasks may already require interpreting measurements, weighing sources or explaining conclusions. A learning decision should start from what the person can demonstrate and where the intended work exposes uncertainty, rather than treating “nontechnical” as shorthand for lacking foundational ability.

Sources: Skills in the AI age: Executive summary; Skills in the AI age: Individuals need a wide range of skills to thrive in digital societies; AI and skills: What we know so far

How can a broad ICT label become a concrete learning target?

Digital competence adds a more useful question than “Can I use a computer?” The European Commission Joint Research Centre’s *DigComp Framework* defines it as confident, critical and responsible use of digital technologies, drawing on knowledge, skills and attitudes. Its five areas describe different kinds of work: information and data literacy; communication and collaboration; digital content creation; safety; and problem solving. Together, they turn a broad ICT label into possible capabilities to inspect. They do not imply that every worker needs equal depth in all five areas, or that digital competence is a single technical level that must be completed before learning about AI.

The first area, information and data literacy, includes finding and filtering digital information, judging its relevance and credibility, and managing information. For a worker, a gap here might be difficulty locating the current policy or telling an authoritative source from an old copy. That is more specific than saying “I need to get better with technology.” It points toward a bounded practice need: search within approved sources, compare versions, and identify the source that governs a decision. The practical target depends on what the job requires; DigComp supplies vocabulary for describing it, not evidence that every worker needs a course in every descriptor.

Communication and collaboration concerns interacting, sharing and participating through digital tools. Content creation covers producing or editing digital material, including combining and reworking content. These areas can overlap in a workflow, but they diagnose different problems. Someone who can draft a report yet struggles to co-edit it with colleagues may need practice with shared documents, permissions or version history. Someone who collaborates comfortably but cannot turn approved material into a clear digital guide has a content-creation gap. Naming which action is difficult helps avoid buying a broad “digital skills” course when a short, relevant exercise or supported practice could address the actual task.

Safety gives a separate lens to protecting devices, personal data, privacy, health and the environment. In work, the immediate learning target could be recognizing what information may be entered into an approved tool, how access is controlled, or where to report a suspected exposure. This is not merely a matter of confidence with an interface: a person may operate software fluently while lacking the knowledge or judgment required to handle sensitive material responsibly. The framework makes that distinction visible. It does not itself tell an employee which specific company policy applies, so the relevant local rule and approved process still need to be identified before practice.

Problem solving includes identifying needs and responses, using digital tools creatively, resolving technical issues and recognizing where one’s digital competence needs development. It can help distinguish a tool-selection problem from a basic operating problem. If a recurring task requires reconciling two sources, the gap might be understanding which function or approved application can support that operation; if an existing tool is failing, the immediate need may be troubleshooting or knowing when to ask for help. Choosing a more advanced application will not necessarily solve a poorly defined task. The descriptor helps name the capability to investigate before committing time to training.

Imagine an employee who prepares a weekly project update by searching shared files, combining comments from colleagues, and publishing a summary. The workflow is hypothetical, not a case reported by DigComp. If the employee repeatedly uses an outdated file, the likely diagnostic area is finding and evaluating information. If comments disappear during handoff, collaboration or content-management practice may be the closer fit. If the employee is unsure whether a confidential attachment can be included, the gap concerns safety and the organization’s applicable rules. If the employee cannot choose a suitable approved format for the summary, problem solving or content creation may be relevant. One workflow can involve several areas, but the training target should be the specific point that blocks the desired output.

This is the framework’s decision value: it helps translate a vague feeling of being “behind digitally” into an observable action that can be practiced or checked. Before selecting learning, the worker can describe the task, the needed output and the moment where difficulty occurs. Then they can identify the DigComp area and an appropriate level of depth for that task. A person who needs to share a document securely does not automatically need advanced digital-content production; someone who edits digital material daily may not need introductory lessons in file handling. Existing experience can satisfy much of the framework already, and a work change may reveal only one newly relevant gap.

A framework can become an intimidating checklist if its five headings are mistaken for five required courses. DigComp is more useful as a reference vocabulary: select the descriptor connected to work the reader needs to perform, then decide whether the gap calls for a policy clarification, practice, feedback or formal instruction. The framework’s documentation describes competencies; it does not demonstrate that completing a course or all five areas produces better employment outcomes. For someone deciding what to learn before advanced AI study, it can clarify whether the obstacle is a concrete digital action in the current workflow. The next step should fit that obstacle and the person’s available time and access, rather than treating the framework as a universal syllabus.

Sources: DigComp Framework

When is data literacy the relevant bridge to AI-assisted work?

Data literacy is a relevant bridge when a worker must understand information used by a tool or interpret a result that informs a decision. OECD’s *AI and skills: What we know so far* names using, analysing and interpreting data among skills needed more broadly than advanced AI-specific expertise. These activities are related but distinct: handling a dataset means working with recorded information; interpreting a result means understanding what its categories, comparisons and limits mean for a question; developing a model means creating or modifying a computational system that learns patterns. A worker may need the first two without needing to build a model or become a data scientist.

The distinction matters because an AI-generated summary can be clear while obscuring the way its source information was assembled. A reviewer may need to know what each category means, which observations are included, whether some are missing, and what the denominator represents before interpreting a comparison. Domain knowledge supplies the context: whether the recorded event corresponds to the process people care about, whether the groups are meaningfully comparable, and what conclusion would be useful. These are not specialist machine-learning tasks, but they require more than accepting a fluent summary at face value. The relevant depth depends on the responsibility attached to the output.

Consider a hypothetical employee asked to review an AI-generated summary of customer feedback from two product versions. The employee need not train the model that produced the summary. To interpret it, however, they need to know how feedback was collected, what counts as a complaint or suggestion, whether the same prompts and channels were used for both versions, and whether duplicate or blank submissions were handled consistently. If one version has far fewer responses, a larger count of negative comments may not mean a higher rate. The reviewer also needs familiarity with the product and customer issue to judge whether categories in the summary capture distinctions that matter. This example illustrates a reasoning need; it is not an OECD case or reported outcome.

In that workflow, data literacy does not mean doing every calculation personally or knowing a particular software package. It means being able to connect a representation to the information and question it is meant to describe. A reviewer might ask: What is counted? Which cases are absent or grouped together? Are the groups being compared on a consistent basis? Does the result address the decision at hand? These questions are practical guidance derived from the OECD’s emphasis on using, analysing and interpreting data; they are not a checklist tested or prescribed by the report. Depending on the task, a colleague responsible for data collection or analytics may answer technical questions, while the domain worker contributes knowledge of the decision and its context.

The separation between analysis and model development also helps prevent overtraining. If a worker’s responsibility is to interpret a dashboard or evaluate a generated summary, studying model architectures may not address the immediate gap. They may instead need to understand a measure, read a data dictionary, practice comparing rates, or learn how the source record is created. Those examples are possible learning targets, not a universal course sequence. By contrast, someone whose chosen work is to build or maintain predictive systems may need programming, statistical methods and deeper technical foundations. The OECD category identifies a broad capability; the target role and output determine its depth.

Data literacy also extends beyond neat tables. Some knowledge workers work mainly with case notes, policy documents, service records or qualitative feedback. Those materials still contain evidence that can be categorized, omitted, duplicated or summarized in ways that affect interpretation. The useful question is not whether a person handles a spreadsheet, but whether a decision depends on information whose origin and meaning they need to understand. A person reviewing written feedback may need to know how comments were solicited and grouped; a person using an operational record may need to understand how an event is entered and what an empty field signifies. These are adjacent examples of applying the same interpretive concern, not a claim that every task is a data-analysis task.

The OECD brief supports treating data use and interpretation as relevant capabilities, but it does not establish how common each task is in a particular occupation, set a proficiency threshold, or require a course before AI use. Its synthesis cannot diagnose an individual’s skills from a job title. A worker can use experience to identify whether information interpretation is already part of the job and where the task has changed. If a new AI-supported process adds a summary or comparison, the learning need may be narrow: understand the input definitions, the way cases were selected, or what a reported percentage compares. If the task contains no data-dependent decision, an abstract data course may not be the most useful next investment.

A practical decision rule follows from that distinction: identify the output you are responsible for, then ask whether you must handle source information, interpret a result, or develop the system producing it. For handling, learn the relevant structure and rules for the records. For interpretation, connect categories, missing information and comparisons to the real question and domain context. For development, investigate the technical prerequisites of the intended system-building work. This is a task-based synthesis, not a sequence attributed to OECD. It lets a nontechnical worker recognize when data literacy is useful while preserving a sensible boundary: understanding evidence can be essential to a decision without making model development part of every worker’s job.

Sources: AI and skills: What we know so far

What should AI literacy mean before specialist technical study?

In *Skill needs and policies in the age of artificial intelligence: OECD Employment Outlook 2023*, AI literacy covers several kinds of capability: understanding basic functions, using AI applications, applying AI concepts across contexts, and undertaking implementation or evaluation. These descriptions distinguish the responsibility involved. A worker who uses an approved application for a bounded task needs enough understanding to use it appropriately; a worker who selects, integrates or evaluates a system needs greater technical depth. AI literacy is therefore not one fixed proficiency shared by every role, but a range of capabilities that can be relevant at different levels.

At the basic end, understanding functions means being able to describe in ordinary terms what a system is intended to do in a workflow and what input or output the user is handling. It need not mean knowing how to derive an algorithm or inspect source code. For example, a staff member using an approved document assistant might need to know that it generates a draft from supplied material, which documents it can access, and which decisions remain with the worker. That understanding helps locate the system’s role in the task and recognize when a question falls outside what the application is set up to do. This is a practical interpretation of the capability category, not a threshold or test supplied by the OECD.

Using an application adds the ability to carry out a defined task with it. A person might use a permitted tool to classify incoming requests, draft a first version of a routine update, or search an internal knowledge base. The relevant outcome is successful task performance within the applicable workflow: choosing suitable input, operating the application, and knowing what to do with the result. Interface familiarity alone may not be enough if a worker cannot connect the output to the original request. At the same time, the OECD description does not mean that every employee needs to use an AI system daily; relevance depends on whether it is part of the work and permitted there.

Applying AI concepts across contexts involves recognizing that a method or result that fits one setting may not carry over unchanged to another. A system used to summarize one kind of document might omit details that matter in a different document type; an automated classification that works with one intake process may use categories that do not fit a revised process. The worker need not infer that the model itself has changed. The practical capability is to notice that context affects fit, ask what the task requires, and identify when another person or process needs to review the result. That is a broader responsibility than operating a familiar interface, though it still does not by itself involve system development.

Implementation and evaluation describe work nearer to the system’s design, integration and performance. Implementation can involve configuring or embedding an AI capability in a process; evaluation can involve assessing whether it performs adequately for a specified use. These responsibilities may require technical knowledge, data access, evaluation methods and authority to change a system. They are not simply more confident versions of everyday tool use. A domain worker may contribute important knowledge about what a useful output must contain, while a technical specialist handles system-level testing or integration. The division of work depends on the organization and task; the OECD chapter describes capability types rather than assigning them to fixed occupations.

For a nontechnical worker deciding what AI literacy means in practice, the categories can be translated into four questions: Can I explain the approved system’s basic role in this task? Can I use it to produce the defined output? Can I recognize when a change in context may alter whether that use fits? Am I responsible for evaluating performance or implementing the system, and do I have the methods and authority that responsibility requires? The questions concern observable work, not a credential. A worker may already answer some through experience, while a new workflow may create a narrow gap. The OECD framework does not supply individual scores or say that a course is necessary to reach any answer.

The distinction between breadth and depth matters when a job calls for more than routine application. Broad literacy can help a worker understand the questions involved in AI use, but a role focused on configuring systems, integrating them with data or assessing performance may need substantial specialist study and supervised practice. That need should be defined by the system and responsibility in view: what will be implemented, which risks or quality requirements must be assessed, and what technical tasks the person will perform. The broad categories do not set a ceiling on learning; they help distinguish a general capacity to engage with AI from the deeper competence required to build or assess particular systems.

The chapter also describes an unsettled field. It notes that definitions of AI literacy vary, that adult measurement is not established in a standardized way, and that course structures for non-experts remain underdeveloped. Consequently, the descriptions should not be read as a validated adult assessment scale or proof that a particular training format causes workplace competence. They name kinds of capability that can guide a discussion of work and learning; they do not show that completing a course produces reliable performance, nor compare alternative teaching sequences. A role may still have a clear immediate need for implementation or evaluation expertise, but determining how to gain that expertise requires evidence about the relevant work and training, beyond the vocabulary in this chapter.

Sources: Skill needs and policies in the age of artificial intelligence: OECD Employment Outlook 2023

Why are judgment, creativity and collaboration part of the skills picture?

The OECD’s *Skills in the AI age: Executive summary* includes critical thinking, creativity and collaboration alongside technical and digital capabilities because AI-supported work still involves deciding what problem to address, considering possible responses, and coordinating action. These categories describe work functions that can interact with tools. They do not establish that the functions are exclusively human, that every job needs them to the same degree, or that they protect a worker from displacement. Their practical value is clearest when connected to a real decision and the responsibilities attached to it.

Critical thinking can shape the question put to a system and the interpretation of what comes back. A worker may need to distinguish the decision that a team actually faces from a nearby question that is easier to answer, identify which assumptions matter, and judge whether an output addresses those assumptions. This involves more than detecting a factual error: a response can be factually plausible yet irrelevant to the choice at hand. The competency is the ability to reason about the problem and evidence in context. An AI application may support parts of that reasoning, but the OECD category does not specify who performs each step or how frequently a particular occupation requires it.

Creativity matters in a different but related way: it can help generate alternatives when the first proposed solution is inadequate, or reframe a task so that the available evidence and constraints are considered differently. In tool-supported work, a person might use generated options as prompts for further thought, then adapt or reject them based on practical requirements the system has not captured. Producing many alternatives is not itself proof of useful creativity; the options need to be connected to the goal and judged against consequences. Nor does naming creativity in a skills framework show that it cannot be assisted by technology. It identifies a kind of contribution that may matter in work, not a guarantee about who or what can provide it.

Collaboration becomes relevant when a decision depends on people with different knowledge or authority. A colleague who understands the AI system’s operation may know what it can output; a domain specialist may understand the customer, case or process; a manager may be accountable for the decision. Bringing those perspectives together can surface a mismatch that any one person misses. Coordination also matters when a new tool redistributes tasks: someone may generate a draft, another person may check it, and a third may approve it. The work includes agreeing what each person must verify and who owns the final action, not just sharing an application.

Consider a hypothetical team deciding whether to change the wording of its standard response to customer complaints after an AI tool groups recent comments into themes. Critical thinking would help the team ask whether the grouping represents the decision it needs to make and what evidence supports the proposed change. Creativity could help generate alternative explanations or response options, especially if the summary does not capture a recurring concern. Collaboration would bring together people who know the complaint process, the source records and the approval rules. The team would then have to communicate uncertainty and agree who is responsible for a change. This is an illustration of how the categories can function together, not an OECD case or reported finding.

The example also shows why these competencies are not interchangeable. More discussion cannot repair a badly framed question unless someone identifies the mismatch; a novel response is not useful unless it fits the evidence and constraints; and individual insight may not lead to a sound decision if relevant colleagues are excluded. Conversely, collaboration alone does not guarantee agreement or accuracy. A process needs ways to surface differing interpretations, make the basis for a choice visible, and assign responsibility for acting on it. These are practical implications inferred from the categories, rather than procedures tested or mandated by the OECD summary.

A reader can make the categories concrete by asking of a changing task: Which part requires interpretation of the problem or evidence? Where might alternative approaches be useful? Which people must coordinate, negotiate or take responsibility for the result? Then ask what work sample, feedback or demonstrated behavior would show that capability in the relevant setting. The answer could be a documented decision, a revised workflow proposal, or an explanation of how different inputs were reconciled, depending on the task. This is a way to inspect the actual contribution at issue, not a universal assessment rubric or advice to accumulate generic ‘human skills.’

The OECD’s inclusion of judgment-related and collaborative capabilities is a competency claim: these kinds of skills belong in the account of capabilities relevant to an AI-shaped work environment. It is not a labor-demand forecast, evidence of a wage premium, or estimate of whether a job will persist. Technology may support, alter or redistribute these activities, and some roles may depend more on technical execution or other requirements. The categories are useful when they point to a responsibility a worker can identify and demonstrate; their presence in a framework alone cannot show that a particular job is protected or that training in a named skill will produce a specific employment outcome.

Sources: Skills in the AI age: Executive summary

What does the fewer-than-1% estimate change—and what can it not decide?

In *AI and skills: What we know so far*, the OECD synthesizes estimates that fewer than 1% of workers need advanced AI-specific skills such as programming or model development, while many more need digital skills and the ability to use, analyse and interpret data. For a nontechnical worker, the estimate changes the starting assumption: broad preparation for working with AI should not be confused with training the whole workforce to build AI systems. It points toward a distinction between widespread ability to engage with AI-supported work and a smaller, specialized set of roles requiring advanced technical expertise. It does not say that the technical work is unimportant, or that a worker who wants to do it should avoid deep study.

The denominator matters. This is an aggregate estimate about workers across the settings assembled in the OECD synthesis, not a quota assigned to each occupation, employer, country or career stage. It gives no worker-level diagnostic and does not tell a person what share of their current tasks involves AI, whether a local employer is hiring for model development, or what skills a particular opening requires. A small overall share can still represent substantial and consequential work, and specialist demand may cluster in particular sectors or places. Someone considering that work should examine the actual responsibilities and entry requirements of their target, rather than treating the aggregate percentage as a ceiling on opportunity or a reason to dismiss technical preparation. It also cannot distinguish workers who already possess relevant technical skills from those who would need substantial preparation, since the synthesis is not a count of individual skill gaps. That distinction matters for a career decision: the same target can involve a small learning step for one person and a major retraining commitment for another.

A hypothetical contrast shows the decision the estimate can clarify. One worker in a domain role might use an approved system to draft or classify material, then apply subject knowledge to determine whether the result fits the task. Another worker might build, adapt or maintain the model and its supporting pipeline. The first situation could call for practical understanding of the system, competent use and judgment about the output; the second could call for programming, data and model-development expertise. These are examples of different responsibilities, not categories the OECD assigns to fixed occupations, and they provide no evidence about how many jobs exist in either group. A real role can combine them, or divide them among a team.

The useful implication is therefore about the question to ask before investing in advanced study: what technical work do I intend to perform? If the answer is to use AI within an existing field, the immediate learning target may be a specific workflow, its information and the decisions for which the worker remains responsible. If the answer is to create or maintain AI systems, the target role’s technical requirements become central, and advanced study may be appropriate. The estimate cannot choose between those paths because it says nothing about an individual’s goals, prior knowledge, access to practice or constraints. Nor does it imply that technical learning has no value outside a narrowly defined specialist job; programming or data skills may support many purposes. It simply weakens the premise that everyone must pursue model development before they can prepare for AI-shaped work. The estimate supplies no return-on-training calculation, so it cannot show that one path is cheaper, faster or more secure than another. Those comparisons require evidence and constraints specific to the worker and target role.

This reading also preserves the counterpoint: an aggregate share below 1% can coexist with high demand for specialists in a particular organization or labor market. An organization developing or deploying its own systems may need several people with deep expertise even when such work is uncommon across the full workforce. Conversely, the presence of AI in a sector does not establish that every employee there needs the same depth. The estimate helps separate a broad baseline question from a specialist requirement; it cannot determine where those requirements fall locally. Use it to resist an automatic leap from ‘AI is changing work’ to ‘I must become an AI engineer,’ then check the concrete work, prerequisites and evidence for the path that actually interests you.

Sources: AI and skills: What we know so far

Why can’t a student progression framework settle an adult worker’s sequence?

UNESCO’s *AI competency framework for students* shows that a learning framework can state an intended progression for a defined population: it organizes 12 competencies across a human-centred mindset, AI ethics, AI techniques and applications, and AI system design, with Understand, Apply and Create levels. Its stated purpose is to guide student curricula. That makes it a useful comparison when asking whether a nontechnical adult can borrow a ready-made order, but it does not provide that answer. The framework’s structure expresses how curriculum designers chose to organize student learning; it is not evidence that workers in different roles, with different prior experience and goals, should move through the same stages.

The transfer question has several parts. Students and adult workers may differ in what they already know, what they need to accomplish, how much time they can devote to study, and whether learning happens in a formal course, on the job or independently. Adults also bring domain experience that may make a particular application or evaluation question immediately relevant, while a student curriculum may be designed to develop a wider foundation over time. These are reasons to test fit, not proof that the populations always learn differently. UNESCO’s framework does not compare adult learners with students or measure workplace performance after alternative sequences, so it cannot resolve those differences empirically. For example, a worker with years of experience in a regulated process may already understand its records, exceptions and accountability, while still needing to learn how a new AI tool changes a particular task. That prior knowledge could shape an efficient learning plan, but the student framework does not say how to incorporate it or measure its contribution.

Nor does the presence of this framework mean the OECD endorsed it as the next step for workers. The two documents have different purposes: *Skills in the AI age: Executive summary* synthesizes broad skill needs and does not set a personal adult curriculum; UNESCO describes student competencies and progression for curriculum design. Putting their categories side by side may prompt useful questions, but it does not create a combined sequence that either source tested. In particular, a student’s progression from understanding to applying to creating should not be converted into a universal rule that every worker must first complete one stage before using AI in a real task. A job may require supervised use now, while a different role may demand deeper design knowledge; the relevant order depends on the goal and setting.

To recommend a sequence for adult workers with confidence, evidence would need to compare learning outcomes from plausible alternatives among adults whose prior skills and work goals are relevant to the decision. It would need to establish what participants could do before learning, what they learned, whether they could apply it to the intended work, and how outcomes differed by sequence or starting point. A curriculum description alone supplies none of that comparative test. UNESCO’s framework therefore cannot establish that its student progression improves adult workplace performance, that it is superior to task-led learning, or that a particular order is necessary. This is a boundary on what the cited framework can answer, not a claim that staged teaching is ineffective.

Still, the framework can offer a design idea: a learning plan may increase responsibility and complexity as the learner moves from understanding a capability toward applying or creating with it. An employer, educator or worker could adapt that idea to a specific task, then check whether the chosen steps produce the needed performance. For example, an adult plan might begin with explaining a system’s role in one workflow, proceed to using it under appropriate review, and add design work only if the person’s goal requires it. That sequence is an illustration of a locally testable plan, not a prescription from UNESCO or OECD. The framework helps make progression visible; evidence about the adult learners and work in question must determine whether the progression fits.

Sources: AI competency framework for students

How should you derive a sensible next step from the OECD categories?

A sensible order starts with the work you want to do, not with a ranking of subjects. The OECD categories can help name possible capabilities, but the decision rule below is this article’s practical inference, not a sequence prescribed or tested by the OECD. First state one outcome you want to produce or take responsibility for, and the recurring task that leads to it. Then ask what currently prevents you from doing that task to an acceptable standard. This keeps ‘learn AI’ from standing in for a specific need: the barrier might be understanding the underlying material, handling information, using an approved tool reliably, or meeting a technical requirement for a different role.

If the barrier is understanding the material or judging whether a result makes sense, check for a foundations gap. The relevant question is not whether you have completed a general course in literacy, numeracy or science; it is whether the task depends on a concept, quantity, assumption or piece of evidence that you cannot yet interpret. If you can identify the gap, choose a focused explanation, worked example or practice task that lets you use that concept on the work in question. If the difficulty remains after that, seek structured instruction or feedback. A foundations gap calls for strengthening the knowledge that makes the task intelligible; it does not automatically call for a broad return to school or a technical credential.

If you understand the work but get stuck finding, organizing, sharing or protecting its information, the gap may be digital or data-related. Narrow it further: are you unable to locate a reliable source, make a useful comparison, handle a file, collaborate through the required system, or follow the relevant privacy practice? Pick practice that exercises that exact operation with material you are allowed to use. Where the obstacle is access to software, records or permission, a course may teach around the problem without resolving it. Ask for the access or clarification first, then decide whether a skill gap remains. The useful test is whether you can complete the work step and explain what you did, not whether you have covered every item in a framework.

If the task and its information are clear but you do not know how to use an available AI application for the desired output, begin with a bounded use case. Confirm that the tool is approved for the material involved, define what a satisfactory output would look like, and try the workflow with review from someone qualified to judge it. The learning need may be practice rather than more concepts: a small, supervised exercise can show whether you can produce, inspect and revise the result in context. If policy, confidentiality, licensing or employer permission is the barrier, resolve that condition before experimenting with live work. Do not treat the absence of permission as evidence that you need a different technical skill.

For someone who wants to use AI in an existing field, the first move is usually to test one relevant workflow while retaining ownership of the domain outcome. For someone aiming to integrate or evaluate systems within a domain role, the target is broader: identify which implementation or evaluation responsibility the role actually includes, then test a small component with appropriate supervision. The first path may need practical application and task-specific judgment; the second may need additional technical depth, access to systems and feedback on the quality of the integration or evaluation. These are different intended outputs, so a single ‘AI course’ cannot be assumed to prepare both. Choose study by the work product you need to demonstrate.

A goal of building or maintaining AI systems is a distinct destination. Write down the system work you intend to own—such as developing software, connecting components, preparing data or maintaining a deployed service—and check the formal prerequisites attached to that work. If the task requires mathematics, programming, domain knowledge or a recognized qualification you do not yet have, a short task trial may reveal interest but cannot replace the missing foundation. Compare a structured course, degree, supervised project or other route by whether it teaches the prerequisite and gives feedback on the intended output. Deeper study is justified when the destination itself requires the capability and the smaller trial confirms a real learning target; it is unnecessary if the desired work does not call for that depth.

Before committing, filter the workable options through the life you have to maintain. Estimate study time and total cost, including travel or equipment; check whether the learning is available where you live and whether an employer can provide paid time, approved access or supervision. Consider health, family responsibilities and the income floor you cannot risk while retraining. These constraints do not say which capability matters, and they are not findings from the OECD framework. They determine whether a proposed route can be sustained now, whether it needs a smaller first step, or whether timing must change. A lower-cost project or employer-supported practice may be more feasible than a credential, while a formal prerequisite may make a longer plan unavoidable.

The practical sequence is therefore: name the output and task; locate the barrier; decide whether it is missing knowledge, unpractised skill, unavailable permission or access, or a formal prerequisite; then choose the smallest learning activity or supervised project that tests the gap. Set a review point and ask whether it changed your ability to produce the output. If not, revise the diagnosis before buying more training. A task-first trial can understate structural barriers or the value of a longer foundation when you are making a deliberate career change. Revisit the choice when the destination, requirements or personal constraints change. The aim is a justified next commitment, not a permanent verdict about how much technical learning you should pursue.

What should you learn next?

Choose one recurring task, name the output you want to own, and write down the single capability or access condition that blocks it today. Make one small, reviewable move tied to that barrier: practise a defined step with approved material, ask for supervised use, confirm permission, or check an existing qualification requirement. Set a date to review whether you can now produce the output to the required standard. If you are still unsure which tasks face change pressure, the free checker at /ai-job-risk-checker provides transparent task-level signals, not a validated probability of displacement. The optional paid /career-roadmap can compare realistic scenarios against your constraints; it does not guarantee employment or income. Your next move may be permission or access, not enrollment. Keep the trial narrow enough that you can inspect the result yourself or ask a knowledgeable colleague to review it. For example, if the obstacle is uncertainty about a workflow, agree on a sample task and a quality check before trying it; if the obstacle is a required qualification, verify the requirement with the relevant provider or employer before paying for preparation. Reassess on the date you chose, and continue only if the step changed what you can responsibly do.

Questions readers ask