A junior analyst asks an AI assistant for a summary of a long service report. The summary is fluent and saves an hour. Three weeks later, a client questions one of its conclusions. The analyst cannot locate the evidence, because the usual practice of tracing a claim through the report has quietly fallen out of the workflow. The tool may still be valuable. The design question is whether it helps people do today’s task while preserving the capacity to check, explain and improve tomorrow’s work.
Designing AI that preserves human capacity is an Institute synthesis, not an established product certification. It asks product teams to examine the abilities users continue to exercise and develop across repeated use. A design can improve immediate performance and still create a dependency that matters when an answer is wrong, a tool changes or access disappears. Conversely, assistance can free attention for harder reasoning and allow novices to learn from examples. Which path occurs depends on task, user, interface and institution.
Preservation is a specific claim
Before judging a product, name the capacity it is meant to preserve. In the analyst’s work, it might be finding a source passage, distinguishing a claim from an inference, recognizing a missing perspective or explaining a conclusion to a client. “Critical thinking” alone is too broad to test. The task should also be named: summarizing a report for a decision differs from drafting an informal update.
A capacity can be preserved even when an external aid is used every day. People have long relied on notes, colleagues and reference works. The concern is not the mere presence of an aid. It is whether the user retains a workable understanding of what the aid does, when it may fail and how to act when it does. The answer may differ between an expert and a beginner.
Capacity development is another claim. A novice may learn by comparing a proposed answer with source evidence and receiving feedback. They may also become adept at accepting plausible text while losing opportunities to form an initial interpretation. A design should specify which learning route it expects and collect evidence across time, rather than treating a pleasant first session as proof of growth.
What offloading research can tell us
Richmond and Taylor review cognitive offloading for retrospective information, such as using a written list to support later recall. Laboratory studies show performance benefits in tested tasks. The review also reports a possible cost: when notes unexpectedly become unavailable, people who had offloaded may perform worse than people who relied on internal memory. The effect concerns particular memory tasks; it is not proof that generative AI generally weakens thought.
The review underscores variability. A person with a different memory profile, a different task or a reliable aid may benefit in another way. The Institute’s translation is to ask what a user needs to be able to do without the tool, and under what circumstances. A shopping list can be lost with modest consequences; a decision-support system can fail during a consequential case. The right fallback depends on that difference.
Offloading can also be strategic. It may release effort for interpretation, conversation or error checking. If the saved effort is immediately filled by more tasks, the hoped-for benefit may never appear. Evaluation therefore needs to inspect what people actually do with the time and attention a system claims to free.
A survey is a signal, not a verdict
Lee and colleagues surveyed 319 knowledge workers about their use of generative AI and collected 936 first-hand task examples. In their analysis, higher confidence in AI was associated with less self-reported critical-thinking enactment, while higher confidence in one’s own ability was associated with more. Participants described shifts toward verification, integration and stewardship of AI outputs. These reports identify design questions worth pursuing.
The study does not show that AI caused a lasting loss of skill. Respondents reported their own effort and examples; the design does not follow a randomized group through years of work or independently test later performance. Confidence may reflect experience, task difficulty or context. A product team should not present the correlation as a measured decline in intelligence or as evidence that every AI user becomes less thoughtful.
It does suggest where to look. Does the interface make verification feasible? Can users compare alternatives and see uncertainty? Do they retain a sense of responsibility for the final work? Those questions can be turned into observable tasks and tested with the intended users.
The whole team matters
Bansal and colleagues analyzed human-AI teamwork in a setting where a person may accept a model recommendation or solve the task themselves. Their results show that the highest standalone model accuracy need not produce the best team result. Verification cost, predictability and human strengths matter in that specific arrangement. The broader lesson is to evaluate the combined workflow rather than use model accuracy as a substitute for it.
For the analyst, the model may be accurate on ordinary summaries but fail on a subtle exception. If the interface makes every answer look equally certain, the analyst has little guidance about where to invest attention. A more useful product might make the source trace visible and mark unsupported inferences. It might slow one high-stakes step while leaving routine formatting fast.
Team performance should include the final decision, time to check it, repair after an error and performance on unfamiliar cases. It should also include whether the person understands the task better after repeated use. A system optimized only for today’s throughput may look successful while tomorrow’s dependency remains unseen.
Build a path from answer to evidence
The analyst should be able to move from a generated sentence to the passage or record supporting it. The passage should be easy to inspect in context. A citation marker that points to a document but not the relevant claim can create an appearance of verification without enabling it. When no source supports a claim, the interface should not invent one.
Traceability helps most when it is part of the normal workflow. If checking requires opening several hidden panels and searching manually, users under time pressure may skip it. A design test can ask whether participants find a planted unsupported claim and how long it takes. The test should use realistic documents, not only a brief example that makes errors obvious.
Source visibility is necessary but not sufficient. People must still decide whether the source is current, whether it supports the conclusion and whether another perspective is missing. A training prompt can ask for a short explanation of that judgment. The purpose is to keep the reasoning legible, not to impose ceremonial clicking.
Choose when to add friction
Buçinca, Malaya and Gajos tested cognitive forcing functions in AI-assisted decisions and found that some forms reduced overreliance in their studied tasks. One approach asks people to consider a case before seeing AI advice. Such friction can encourage independent thought, but the result does not justify adding a hurdle to every interaction.
A repeated pause can become routine and lose meaning. It may also burden someone using assistive technology or handling a large caseload. The design question is where an error is costly, where independent judgment is valuable and where an additional step improves outcomes enough to justify its cost. The answer should be measured rather than assumed.
A product might offer an initial-answer step during training, then use targeted checks for unusual cases in routine work. Another might ask the user to identify the most uncertain claim before revealing a model’s confidence. These are hypotheses for testing, not guaranteed best practices. The relevant outcome is appropriate reliance, including using a dependable answer when it is safe to do so.
Teach with assistance, then vary it
A learning design can sequence support. First a learner attempts part of the task, then compares it with an AI suggestion, then receives feedback on the difference. Later the system reduces the scaffolding or presents a novel case. This makes progress visible beyond the ability to reproduce one assisted performance.
The sequence should not force manual work merely to display discipline. In some tasks, a tool safely removes rote demands so the learner can practice a more important judgment. The team must decide which elements are foundational to understanding and which can be offloaded. A domain expert and the intended learner should both inform that decision.
UNESCO’s guidance for generative AI in education and research argues for a human-centred approach to pedagogical design and human capacity. It is a policy guide, not experimental proof of one teaching method. Its relevance is to keep educational aims, learner agency and equitable access in view when a school chooses tools and rules.
Feedback should make a person stronger
A system can report that an answer is wrong without explaining why. A more educational interaction identifies the missing assumption, conflicting source or step in a reasoning chain. It can invite the user to try again before showing a complete solution. But feedback must be accurate and understandable; confident but mistaken coaching can train the wrong habit.
Product testing should therefore assess the feedback itself. Experts can review a sample for correctness and usefulness. Learners can be tested later on related but changed tasks. If they improve only while the same prompts remain on screen, the evidence supports assisted performance, not necessarily capacity growth.
Feedback also has an emotional and social setting. A worker may not experiment if every disagreement with the model is counted against them. A learner may avoid showing uncertainty if the system ranks them publicly. Institutional rules can determine whether a technically sound feedback feature is used for learning or for surveillance.
Design for interruption and failure
The analyst’s tool may be unavailable, its source index may be incomplete or a new model version may produce a different answer. A capacity-preserving workflow has a fallback. People know where original records live, how to document uncertainty and who can help with an unfamiliar case. The fallback need not be as fast as the AI path, but it must be credible.
A realistic exercise can briefly remove assistance and ask users to complete a core task. This is not a test of personal worth. It identifies whether the organization has retained necessary knowledge, documentation and staffing. Another exercise can seed a plausible error and watch whether users detect and repair it. Both expose dependencies that a satisfaction survey may miss.
Some skills can be distributed across a team rather than held by every person. The organization should be explicit about that choice and protect access to the people who hold them. If no one can explain the decision when the tool is wrong, capacity has been lost at an institutional level even if individual users are happy with the interface.
Measure outcomes across time
A pilot should establish a baseline for the named task. It can compare users with different forms of AI support on immediate accuracy and speed, then test later work with altered examples or without the tool. It can record whether people detect errors, explain decisions and learn to ask better questions. Follow-up matters because convenience on day one can diverge from competence after months of use.
Measurements must match the intended capacity. Time saved measures efficiency, not discernment. A self-report of confidence can be useful but cannot substitute for observing error detection. A high override rate may indicate active scrutiny or a poor model. A low rate may indicate reliability or passive acceptance. Cases and reasons are needed to interpret both.
Evaluate differences among users. A novice, an expert and a person using accessibility supports may benefit from different design choices. Aggregate performance can conceal that one group gained speed while another lost the ability to complete essential tasks. Review privacy and consent when collecting interaction traces; excessive monitoring can undermine the conditions for honest learning.
Product governance is part of design
Amershi and colleagues offer human-AI interaction guidelines covering expectations, feedback, errors and control. Their guidelines were evaluated with design practitioners across existing products, but applying them is not a guarantee of long-term capacity. A team should use them as prompts and then verify outcomes in its own context.
Procurement and deployment decisions can require a capacity statement: what users should be able to do after six months, what the AI is allowed to do for them, and how the organization will check. Release reviews can ask whether an update changes verification, skill practice or fallback routes. A team can revise those requirements when observed use differs from the original plan.
Responsibility should not be placed solely on the person at the interface. If workloads prevent checking, a “verify” button is inadequate. If managers reward only speed, users may avoid the very reflection the product claims to support. Preserving capacity requires time, authority and a route to change the system when a pattern of errors appears.
What the evidence does not show
Offloading experiments do not establish a universal loss from AI assistance. A survey of knowledge workers does not prove that AI causes long-term critical-thinking decline. Human-AI teaming studies and cognitive-forcing results are task-specific. Design guidelines and UNESCO policy do not certify the effectiveness of a product. The article’s capacity-preservation framework is an Institute synthesis requiring direct evaluation.
There is no single skill-retention number that applies to every user and task. A system may appropriately offload one routine operation while supporting another ability. The test is whether the design’s stated human outcome is visible in behavior across time, including when the tool is wrong, changed or absent.
Return to the disputed summary
With a better workflow, the analyst opens the summary’s source trace, finds the contested passage and explains which conclusion it supports. They correct the unsupported sentence and record the error so colleagues do not repeat it. The tool still saved time. The saved time was partly invested in work the analyst could understand and defend.
AI that preserves human capacity makes help and learning compatible. It defines the capacities that matter, lets people exercise them at useful moments and checks whether they remain available later. The standard is not a reassuring interface label. It is what people and institutions can still do when an answer needs a human explanation.
Research references
- Richmond, L. L., & Taylor, R. G. (2025). The benefits and potential costs of cognitive offloading for retrospective information. Nature Reviews Psychology, 4, 312–321. View source
- Lee, H.-P., Sarkar, A., Tankelevitch, L., Drosos, I., Rintel, S., Banks, R., & Wilson, N. (2025). The impact of generative AI on critical thinking: Self-reported reductions in cognitive effort and confidence effects from a survey of knowledge workers. Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems, Article 1121. View source
- Bansal, G., Nushi, B., Kamar, E., Horvitz, E., & Weld, D. S. (2021). Is the most accurate AI the best teammate? Optimizing AI for teamwork. Proceedings of the AAAI Conference on Artificial Intelligence, 35(13), 11405–11414. View source
- Buçinca, Z., Malaya, M. B., & Gajos, K. Z. (2021). To trust or to think: Cognitive forcing functions can reduce overreliance on AI in AI-assisted decision-making. Proceedings of the ACM on Human-Computer Interaction, 5(CSCW1), Article 188. View source
- Miao, F., & Holmes, W. (2023). Guidance for generative AI in education and research. UNESCO. View source
- Amershi, S., et al. (2019). Guidelines for human-AI interaction. Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems, Paper 3. View source