What NIST AI 600-1 Asks Organizations to Manage at Work

What is NIST asking an organization to do?

NIST AI 600-1 asks organizations to manage generative AI risks where the system will actually be used. The short version is: assign responsibility, describe the work context and affected people, identify relevant risks, test what matters, choose controls, and keep watching for changes and incidents. NIST published the profile on July 26, 2024, as a cross-sector companion to AI RMF 1.0. It is voluntary guidance, not a job-security score or universal checklist. [NIST publication record](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence) identifies its scope and date; the full [AI 600-1 profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf) supplies the suggested actions.

That distinction matters at work. A generative system is not just a model name or a feature in a software package. It is a system in a workflow: someone provides information, the system returns or acts on content, people interpret the result, and something happens downstream. A writing aid used to brainstorm internal meeting titles is a different use from one that drafts a response to a benefits claimant, summarizes a contract, or suggests a code change shipped to customers. The same model may sit inside all four workflows, but the information, affected people, consequences, and checking needs differ.

The profile therefore gives an organization a way to ask better questions before and during use. What task is being supported? What data enters? What output is expected? Who will rely on it? What could go wrong, and how serious would that be here? Which parts can be checked, by whom, and before what decision? What happens when the vendor changes the service or an incident occurs? The document organizes possible answers; it does not answer them for a particular employer.

The reader should also separate this work from employment forecasting. AI 600-1 names risks in systems and their use, not the probability that a role will disappear. Some duties may be exposed to technical change while other work remains dependent on judgment, trust, physical presence, or accountability. A risk-management profile cannot tell an individual whether to quit, retrain, or accept a new role. Its workplace relevance is more immediate: it helps specify what must be true for a particular use to be responsible enough to continue.

A team considering automated meeting-note summaries, for example, can start by recording the meeting types, information sensitivity, people who may be mentioned, who reads the summary, and which actions may follow from it. Then it can decide whether some meetings are excluded, whether names should be removed, how errors are corrected, and who owns the service relationship. This is an illustration of applying the profile, not a documented NIST case. Each later section unpacks one part of this sequence without assuming every use needs the same controls.

Sources: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile; Artificial Intelligence Risk Management Framework (AI RMF 1.0)

How does the profile fit the wider NIST framework?

AI 600-1 takes the general structure of AI RMF 1.0 and applies it to risks that are unique to or heightened by generative AI. The parent framework has four functions: Govern, Map, Measure, and Manage. NIST describes them as a way to organize continuing risk work, not four mandatory stages that every organization must complete in a fixed order. Governance is cross-cutting; it shapes how the other functions are carried out. The [AI RMF Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) says actions are not a checklist or necessarily ordered, and the [AI RMF 1.0 report](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf) defines the framework’s functions and subcategories.

Govern asks how an organization builds responsibility and risk management into its culture, policies, decision rights, and work practices. Map asks what the system is for, how it will be used, what people and conditions matter, and what impacts are plausible. Measure asks how an organization will assess relevant properties and risks, including through tests, metrics, qualitative review, monitoring, and documentation. Manage asks how it will prioritize and respond: accept, mitigate, restrict, transfer, pause, or stop a use according to context and tolerance. These activities inform one another. A test may reveal that the original context description missed an important user group; an incident may change policy or prompt a new test.

The profile’s contribution is not a separate governance philosophy. It adds a generative-AI risk taxonomy and suggested actions that can be read alongside relevant AI RMF subcategories. Its introduction says the profile primarily addresses four considerations developed through its working process: governance, content provenance, pre-deployment testing, and incident disclosure. It also discusses risks such as confabulation, privacy, harmful bias, information security, intellectual property, and human-AI configuration. The action tables select some framework subcategories and connect suggested actions to risks and actor tasks. NIST expressly cautions that the included actions are not exhaustive and that applicability depends on the system, lifecycle stage, organization, and actor role.

That design is useful for a workplace because it discourages treating a long list as a compliance scavenger hunt. A team need not claim it has completed every subcategory to say it used AI 600-1. It should instead explain which risks it considered, why certain actions apply, which do not, and what evidence informed the decision. The [NIST AI RMF Playbook](https://airc.nist.gov/airmf-resources/playbook/) makes the same boundary explicit: its suggestions are voluntary and users may borrow as many or as few as fit their use case. The Playbook is an aid for the parent framework, not a certification standard or a second mandatory layer.

There is also a date boundary. AI 600-1 is a 2024 publication grounded in AI RMF 1.0. NIST’s current [framework overview](https://www.nist.gov/itl/ai-risk-management-framework) says the 1.0 framework is being revised. That page is current operational context, not a retroactive rewrite of the profile. Organizations using the material should check NIST’s live pages for updates and also follow applicable laws, sector requirements, contracts, and internal policies. Voluntary guidance does not cancel obligations that arise elsewhere.

A practical reading method is to start with the actual use, find the relevant risk discussion and AI RMF function, then inspect suggested actions for the actors involved. A company deploying a hosted service may own workflow mapping, access rules, end-user training, and output checks while the provider owns model-development controls. The deploying organization should not claim it performed controls outside its role; it should document how it assessed gaps, what it asked of the provider, and what residual uncertainty it accepted. This actor-specific reading preserves the framework’s flexibility without turning it into an excuse for vague accountability.

Sources: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile; Artificial Intelligence Risk Management Framework (AI RMF 1.0); AI RMF Core; NIST AI RMF Playbook; AI Risk Management Framework

What should governance and accountability look like in practice?

Governance should make clear who may use a generative system, for which work, with what boundaries, and who is responsible when conditions change. A policy that only lists approved products does not settle how a tool can be used inside every workflow. A product can support low-stakes drafting in one team and influence a consequential decision in another. AI 600-1’s governance suggestions connect policy, assigned roles, risk tolerance, documentation, education, stakeholder engagement, change management, incident response, monitoring, and eventual decommissioning. The [NIST Playbook](https://airc.nist.gov/airmf-resources/playbook/) describes its own governance actions as adaptable suggestions, not compulsory steps.

Start with decision rights. Someone needs authority to approve a use, set limits, request evidence, and pause the workflow. The title of that person will vary by organization and risk. A small firm may combine responsibilities; a larger one may involve operational leaders, information security, privacy, procurement, legal counsel, records management, accessibility, and affected workers. The important point is that the person closest to the output should not silently inherit every organizational risk simply because they are the last human to see it. End users can report a problem, but they may not control vendor terms, data retention, system configuration, or the decision to buy the product.

Policy becomes useful when it is specific enough to guide action. It can state which information may be entered, which uses are prohibited or require review, what must be disclosed, how outputs may be shared, and where staff should take an uncertain case. It can distinguish internal drafting from external commitments, and support from final decision-making. It can also describe records to keep, permitted tools, approved accounts, and escalation routes. The profile does not prescribe one policy template; the organization must translate its risk tolerance and obligations into directions workers can follow during ordinary tasks.

Imagine a team using a generative tool to draft customer replies. A blanket approval says the product is allowed; a blanket ban avoids this use but may also rule out lower-stakes assistance elsewhere. A context-specific governance decision would identify which reply types are in scope, what source material the system may use, which promises it may not make, who reviews sensitive cases, and who can suspend use if quality declines. It would record the rationale and the owner of the decision. This is an illustration, not a reported deployment or an outcome claim.

Governance also asks whose perspective is missing. Staff who use a workflow may know where an output enters a decision, what exceptions are common, or which correction work is invisible in management reports. People affected by the output may see errors or barriers that designers do not. NIST’s broader framework encourages multidisciplinary perspectives and engagement with relevant actors. Participation does not guarantee agreement or eliminate risk; it can surface assumptions early enough to change a design, scope, or control.

Responsibility should extend over time. An approval should have a review trigger: a material model or vendor change, a new data source, a new user group, a changed downstream decision, a privacy or security incident, a pattern of overrides, or evidence that expected review cannot be done. A change log can record what changed, who assessed it, whether testing was repeated, and whether permission or training changed. A retirement plan matters too. Workflows need a way to revert to an earlier process if the service becomes unavailable, is withdrawn, or no longer meets requirements.

For workers, sound governance has a practical sign: the organization explains what remains the worker’s responsibility and provides enough time, training, access to source information, and authority to meet it. If an employee is asked to verify a generated summary but cannot inspect the underlying record or correct an error, a policy calling for human review may be symbolic. For managers, governance means naming the owner of the process rather than treating risk as a personal failure by the person who clicked a button.

Sources: Artificial Intelligence Risk Management Framework (AI RMF 1.0); NIST AI RMF Playbook

Which kinds of harm does NIST want organizations to consider?

AI 600-1 gives organizations a set of potential risk categories to investigate; the labels are prompts for analysis, not findings that a workplace has experienced each harm. NIST’s taxonomy includes confabulation, harmful bias and homogenization, privacy, information security, intellectual property, information integrity and provenance, human-AI configuration, misuse-enabling content, and value-chain integration. The profile also highlights governance, pre-deployment testing, content provenance, and incident disclosure as primary considerations. These categories can be organized by where a risk enters a work process: in generated material, in information handling, in human reliance, or in the system and supply chain.

Confabulation refers to generated content that is erroneous or false but may appear plausible. In an office workflow, a summary can omit a qualification, an answer can cite a source that does not support the claim, or a draft can combine correct fragments in a misleading way. The issue is not that every generated sentence is wrong, or that creative invention is itself a defect. The relevant question is whether the output is presented or used as factual information and what happens if an error survives. A brainstorming prompt can tolerate speculative suggestions; a report used to decide eligibility, compliance, or payment needs a different evidence threshold.

Bias and homogenization point to separate concerns. A system may reproduce or amplify harmful patterns in training data or outputs. It may also narrow language, recommendations, or options toward a familiar average, reducing meaningful variation. An organization should ask which groups are represented in its use context, whether outputs differ in ways that matter, and whether the system’s framing hides alternatives. The profile does not establish that every system will discriminate or that a single fairness test can settle the issue. Testing has to match the task, population, and decision where the output could matter.

Information risks begin before an answer appears. A worker may paste personal, confidential, or commercially sensitive material into a service whose data handling is not understood. Generated text may expose information, reproduce protected content, or blur the provenance of a claim. The risks can be connected: a sensitive record is entered, transformed into an inaccurate summary, then circulated without indication of its source. Data minimization, access control, retention understanding, provenance practices, and review of output handling are possible controls, but their appropriateness depends on the service and the organization’s legal and contractual duties.

Security and misuse concerns include attacks, unauthorized access, or use of capabilities to facilitate harmful conduct. In work settings, a team may need to understand how generated outputs enter software, knowledge stores, communications, or other systems, and how those connections are secured. AI 600-1 is a cross-sector risk profile, not a complete security standard. Teams should coordinate with established security practices and qualified specialists rather than treating the profile’s categories as a substitute for them.

Human-AI configuration concerns how people understand and rely on the system. A polished answer can invite more trust than the evidence warrants. At the other extreme, a process may ask a person to approve every output without giving them time, expertise, or a realistic way to check it. That is not automatically a safeguard. The organization needs to consider who can challenge an answer, whether responsibility is clear, how automation bias might appear, and what conditions require escalation or manual handling.

Finally, value-chain and integration risks arise because an organization may depend on models, data, hosting, interfaces, or services supplied by others. A change or failure at one point can alter the behavior of the whole workflow. A vendor’s assurances can help answer some questions, but they do not establish that the organization’s specific use is safe. The organization should decide which risks it can assess internally, which require provider information, and which remain uncertain. NIST’s list is not a severity ranking, prevalence estimate, or instruction to apply maximum controls everywhere. It is a structured way to ask which possible harms are relevant, how consequential they would be, what can be observed, and what response is proportionate.

Sources: Artificial Intelligence Risk Management Framework (AI RMF 1.0)

How should organizations map the work context and affected people?

Mapping is the work of describing the use before debating whether it is safe enough. A useful description says what task the system supports, what information enters, what it returns, who uses the result, who else may be affected, and what downstream action can follow. It also names the setting, intended purpose, users, affected groups, dependencies, assumptions, and known limits. In AI RMF terms, Map gives the organization a context to which risk analysis and later measurement can attach. Without that context, statements such as “the tool is accurate” or “we have a human in the loop” are too general to support a decision.

A task map should follow the information from start to finish. Consider a document-intake workflow. A system might extract names, dates, and document types from files. That is different from deciding whether someone qualifies for a service. The first task still carries privacy and extraction-error risks, but the second introduces judgment, policy interpretation, and direct effects on a person. If the organization describes both as “automating intake,” it may miss the point at which a generated result begins to influence a decision. A clear map separates extraction, categorization, recommendation, decision, communication, and appeal or correction.

For each step, record the human and system roles. Who supplies the prompt or data? Who configures the system? Who receives the output? Does another application store, transform, or act on it? Can the user see the source material? Is the output copied into an official record? Can the person affected challenge it? A workflow diagram can expose handoffs that a product description hides. It can also show where a worker’s expertise is used: choosing the right input, spotting an exception, explaining a decision, or taking responsibility for the final communication.

Affected people are not limited to the user who sits at the interface. They may include people whose records are processed, customers who receive a generated answer, colleagues whose work is summarized, applicants screened by a system, or people represented in generated content. Some affected individuals may never know that a system participated. Mapping should therefore ask who bears the consequence of an error, not only who benefits from faster drafting. NIST’s general AI RMF frames impact in relation to individuals, groups, communities, organizations, society, and the environment, and stresses that third parties can complicate measurement and use.

Context also includes constraints that can change system behavior or risk. Does the task involve a regulated or confidential record? Does it happen under a deadline? Are users trained in the subject matter? Is output used in a language or format that can be checked? Does the service rely on retrieval, plugins, external databases, or integrations? What happens if it is unavailable? Are there fallback procedures? These are not abstract questions. They identify the conditions under which an output is created and the means by which it can be reviewed or corrected.

A map should not overstate precision. It may be impossible to know every future use or every group that could be affected. The organization can mark assumptions and unknowns, limit the approved scope, and revisit the map when evidence changes. It can also test for foreseeable repurposing: a tool introduced to draft internal notes may later be used to prepare external advice, even if that was never its original purpose. Access restrictions, interface design, training, and monitoring can reduce drift, but they cannot guarantee that users never adapt a tool in unplanned ways.

This is where a task-level view differs from an occupational label. Saying a role is exposed to generative AI does not tell a manager which step can be assisted, what quality threshold is needed, or where accountability remains. A map may reveal that one part of a job is repetitive and information-rich while another depends on negotiation, contextual judgment, or relationships. It can guide a proportionate work redesign discussion. It cannot predict whether the employer will adopt the system, how staffing will change, or whether demand for the occupation will rise or fall.

A practical mapping record can fit on a few pages: purpose and boundary; task sequence; users and affected people; data and system dependencies; expected benefits; plausible failure modes; decision points; known evidence and gaps; and triggers for reassessment. This format is an editorial recommendation derived from the framework’s context-first logic, not a mandatory NIST artifact. Its test is whether a colleague who did not attend the original discussion can understand what was approved and what would make that approval no longer appropriate.

Sources: Artificial Intelligence Risk Management Framework (AI RMF 1.0); AI RMF Core

How should organizations test and measure before relying on outputs?

Organizations should test the combined system and workflow against the task they intend to perform, using criteria linked to the consequences of failure. A demonstration or general benchmark rarely establishes that a tool is suitable for a local process. The profile calls attention to pre-deployment testing, while the broader AI RMF says measurement can include quantitative, qualitative, or mixed methods and should continue during operation. NIST’s [AI RMF appendix on AI risks](https://airc.nist.gov/airmf-resources/airmf/appendices/app-b-how-ai-risks-differ-from-traditional-software-risks/) explains that AI systems can differ from traditional software in testing, opacity, privacy, reproducibility, maintenance, and side effects. This supports context-specific testing, not a claim that every AI system fails in these ways.

First define the intended outcome and unacceptable failures. If a tool drafts routine internal summaries, relevant measures might include factual fidelity to source documents, omitted caveats, correction time, and the rate at which reviewers need to rewrite the result. If it drafts an externally sent response, the organization may also care about unsupported commitments, privacy, tone, accessibility, and whether the text directs a person to an accurate next step. One overall accuracy figure would conceal these differences. The metric should connect to an actual use and a decision about continuation or restriction.

Then build representative test material. Include ordinary cases as well as boundary cases, rare formats, incomplete inputs, ambiguous language, and cases that should trigger abstention or escalation. Where groups may be affected differently, test relevant variations rather than assuming an aggregate average is enough. Use examples that the organization is allowed to process, protect sensitive information, and document where the test set came from. A small internal set can reveal obvious workflow problems but cannot prove general performance across every future input. A test report should state what it covers and what it does not.

Evaluate the workflow rather than only the model response. Check whether staff can access the source, recognize a failure, correct it, and record the correction. Observe the time and effort needed for verification, not just the speed of first output. A draft produced quickly may shift work into fact checking, escalation, formatting, or repairing a mistaken record. Measure the complete process with a meaningful baseline, such as the existing method or an unassisted sample, while recognizing that the comparison may be imperfect. The output can be faster and still be lower quality; it can also be useful for some cases and unsuitable for others.

Qualitative review has a place alongside counts. Subject-matter experts can examine whether explanations omit necessary context, whether the system handles exceptions coherently, or whether users misunderstand what an output signifies. People who perform the task can identify workarounds and review burdens that a dashboard does not record. NIST’s framework encourages traceable documentation and recognizes that metrics may be unavailable, incomplete, or poorly matched to a use. If a risk cannot be measured, that limitation is not proof of high or low risk; it is an uncertainty to manage.

A test plan should predefine what result would change the decision. If errors above a chosen threshold require restriction, say who chose the threshold and why it fits the impact. If a particular error cannot be tolerated, define a control or exclusion for it. If an organization cannot obtain enough evidence, it can limit the pilot, keep the system in a low-consequence support role, seek provider information, or decline deployment. A favourable test should not be turned into open-ended permission for uses that were never assessed.

Testing continues after launch because the workflow and dependencies can change. The organization can sample outputs, monitor errors and overrides, collect user feedback, track incidents, and repeat tests after material updates or changes in user population or task. A provider may change a model, prompt layer, retrieval source, interface, or service condition. Users may also adapt their behavior once a tool becomes familiar. Monitoring needs a named owner, a review interval suited to the consequences, and an escalation route for evidence that the original assumptions no longer hold.

There are limits to testing. A bounded set of examples cannot enumerate all prompts or foreseeable misuse; a benchmark may not represent local language or domain terms; users may behave differently under test conditions; and a measured quality level today does not guarantee the same performance after a change. Independent review can help identify blind spots or conflicts of interest, especially for consequential uses. But a second reviewer does not make an inadequate test adequate. The key is to make claims no broader than the evidence: these cases were tested, these results were observed, these uncertainties remain, and this is the decision they support.

Sources: Artificial Intelligence Risk Management Framework (AI RMF 1.0); AI RMF Core; How AI Risks Differ from Traditional Software Risks

What does meaningful human review mean here?

Human review is meaningful only when the reviewer can understand what they are checking, has the information and time to check it, can change or reject the output, and has authority to escalate a problem. A human name attached to an approval step does not establish that review happened in a useful way. AI 600-1’s suggested actions include attention to human-AI configuration, user involvement, verification, feedback, and overrides. The precise review arrangement depends on what the system produces and what could happen if an error passes through.

The reviewer’s first question should be: what claim or action am I being asked to validate? If a system drafts a summary from records, the reviewer may need to compare each material statement with the underlying record, not merely judge whether the paragraph sounds plausible. If the system generates a customer response, review may need to check policy, dates, eligibility or contractual terms, source links, and whether the response promises something the organization can deliver. A reviewer who sees only the generated text may be unable to check provenance or completeness.

Next ask what authority the reviewer has. Can they edit the output? Can they return it for correction? Can they route it to a specialist? Can they decline to use the system without penalty? Can they stop a workflow if a pattern of errors emerges? If the only permitted action is to click approve, the organization has designed a confirmation step, not a robust review process. Reviewers also need training on known limitations, the task’s quality standard, how to access sources, and how to report recurring failure patterns.

Workload is part of the control. A reviewer responsible for a large volume of outputs under a short deadline may not be able to inspect each result carefully. The organization should estimate review time during testing, staff the workflow accordingly, and decide whether review is universal, sampled, risk-triggered, or reserved for specified categories. Sampling can help monitor routine performance but does not provide individual assurance for every output. Risk-triggered review requires a reliable way to identify the trigger. There is no universal ratio of human to automated work that NIST prescribes.

Human performance also has limits. Familiar language can feel persuasive even when it is unsupported. Repeated exposure to mostly correct outputs can make an occasional error harder to notice. Conversely, distrust can lead people to reject useful suggestions without examining them. A review process can counter these tendencies by requiring source checks for critical claims, showing uncertainty or provenance where available, separating draft generation from final decisions, and inviting reviewers to record disagreement. These steps should be tested in context; a warning label alone does not establish that people understood or followed it.

A useful division of labor gives the system a bounded role and preserves human accountability where it is needed. For example, a tool may extract possible dates from a form, while a trained worker checks uncertain entries and makes the consequential determination under existing policy. That division is not inherently appropriate for every organization, and the example is illustrative. Its value is that it separates a potentially supportable subtask from a final judgment with a different evidence and accountability threshold.

The organization should document overrides and feedback as operational evidence, not as a score of worker compliance. If staff repeatedly correct the same type of omission, that may point to a system limitation, unclear input, flawed training, or an overly broad use. If workers rarely override outputs, that could mean good performance, but could also mean the process makes correction difficult or discourages disagreement. Counts need interpretation alongside case review, access to underlying evidence, and worker input.

Finally, human review does not transfer all organizational responsibility to an individual user. Management decides what system is procured, how it is configured, which tasks are allowed, what staffing and training are available, and what consequences follow from an error. A worker can be accountable for following a clear procedure within their control; they cannot compensate for missing sources, impossible workloads, undisclosed vendor changes, or unclear decision rights. NIST’s focus on governance and actor roles supports this broader view: useful oversight is designed into the process rather than assumed at the final click.

Sources: Artificial Intelligence Risk Management Framework (AI RMF 1.0); AI RMF Core

What changes when the tool comes from a vendor?

A vendor tool adds dependencies that the organization may not be able to inspect or control directly. The provider may operate the model, hosting, interface, updates, security practices, data handling, or support process. The deploying organization still controls its purpose, user access, workflow, input choices, reliance on outputs, and some monitoring. AI 600-1 treats value-chain considerations as part of risk management and suggests actions around third-party assessment, documentation, fallbacks, incidents, and ongoing monitoring. Those are suggested actions; their application depends on the organization’s role and the service available.

Procurement should begin with the use case, not a generic promise that a product is secure or responsible. Ask what information the service receives, whether it may be retained or used for other purposes, where it is processed, who can access it, and how deletion works. Ask what model or service components are involved, how updates are communicated, what documentation and testing evidence are available, and what controls the customer can configure. Ask what incident notifications, audit records, service availability, and exit options the contract supports. Questions should be adapted to law, sector rules, bargaining obligations, and the data involved.

A provider’s answer has a boundary. A security attestation may inform the assessment of particular controls, but it does not prove that generated outputs meet the organization’s task standard. A benchmark result may describe tests run by the provider, but not necessarily the organization’s local documents, users, policy, languages, or exception cases. A statement about data use may cover one product tier or configuration but not another. Procurement teams should record the evidence source, date, scope, and remaining uncertainty rather than converting marketing language into a general assurance.

The organization also needs an account of the end-to-end system. A purchased interface may connect to a model, retrieval layer, internal documents, plugins, and enterprise data sources. A change at one component can affect output quality, data access, or downstream actions. Map the components and owners as far as the information permits. If the provider does not disclose details, identify what cannot be verified and decide whether the use can be narrowed to reduce dependence on unknown behavior. A lack of transparency is itself a constraint on the depth of assurance, not proof that a service is unsafe.

Third-party risk management needs a fallback. If an outage, price change, contract change, or service retirement interrupts the workflow, can the organization return to a manual process or use another approved method? Who decides? Are staff trained to handle the fallback? Are records, prompts, and outputs exportable in a usable form? These questions are especially practical for recurring work. A workflow that has no alternative may create pressure to continue using a service even when a problem has emerged.

Change management should specify which vendor changes trigger review. A major model revision, new feature, new data use, integration, or revised terms may alter the risk picture. The organization may need to repeat a subset of tests, notify users, change access, or pause one application while retaining another. It should know how to hear about relevant changes and who will interpret the notice. A provider’s general release schedule may not provide enough detail for every customer decision, so contracts and internal monitoring need to work together.

Responsibility is shared but not interchangeable. Providers may be best positioned to assess development practices and underlying model behavior. Deployers are best positioned to understand local tasks, affected people, and downstream decisions. Integrators may control prompts, data flow, or interfaces. Users see how the system behaves in everyday work. An organization should not claim that vendor responsibility removes its own duty to govern use; neither should it pretend it can independently verify facts that only the provider can supply. Documenting the boundary makes the remaining choices more honest.

For an employee, practical signs of a managed vendor relationship include an approved work account, clear data rules, a contact for questions, instructions for reporting unexpected output, and a stated fallback if the service fails. If a manager tells workers to use a personal account or upload sensitive material without clarifying the terms, the problem is organizational governance. Employees can ask what information is permitted and where concerns should go, but vendor due diligence is not a burden they can solve alone.

Sources: Artificial Intelligence Risk Management Framework (AI RMF 1.0); NIST AI RMF Playbook

What can the profile tell you about a job, and what can it not?

AI 600-1 can help an organization examine risks in an AI-supported workflow; it cannot estimate whether a particular worker will lose a job. Its unit of analysis is a system and its use context, not a person’s employment prospects. It offers no job-loss probability, occupation ranking, wage forecast, adoption rate, or guarantee that a role is safe. A task can be technically exposed to automation or assistance without an employer adopting a system, redesigning the role, reducing staff, or changing hiring. Those are separate events that require separate evidence.

This is why the profile’s task and actor language can be useful to workers without becoming an individual career forecast. A worker can ask which recurring tasks are supported by a tool, which sources and judgments remain essential, what review effort is added, and how accountability is assigned. Those observations may help prepare for a conversation about workflow design, training, or adjacent duties. They do not reveal what an employer intends to do or whether a worker can secure a particular move.

The International Labour Organization’s 2025 brief illustrates the difference between exposure and displacement. The brief summarizes a global working-paper analysis combining task-level data, expert input, and AI predictions at the six-digit occupational level across nearly 30,000 tasks. It defines four exposure gradients. The brief reports a mean automation score of 0.29 in 2025, compared with 0.30 in 2023, and says one in four workers globally is in an occupation with some degree of exposure. It also concludes that most jobs are more likely to be transformed than made redundant because human input remains necessary. These are modeled exposure estimates, not observations of employer adoption or measured job losses, and they are not forecasts for a specific country or individual. [ILO, “Generative AI and jobs: A 2025 update”](https://www.ilo.org/publications/generative-ai-and-jobs-2025-update) provides the method summary and limits.

For a worker evaluating a role, the more actionable question is often “which tasks are changing, and how?” Repeated document extraction may be technically easier to assist than negotiating an exception, explaining a decision to a customer, or resolving conflicting evidence. Yet exposed tasks do not automatically vanish: an organization may add them to existing work, increase output expectations, redesign the process, or decide the costs of verification outweigh the benefit. The direction depends on tool capability, reliability in context, integration cost, policy, customer needs, labor relations, and management choices. AI 600-1 helps govern the system decision; it does not resolve these labor-market mechanisms.

It also cannot tell a worker to become an AI specialist. A proportionate response may be to learn the approved tool well enough to verify its output, strengthen domain judgment, document recurring errors, or develop a small workflow improvement. Another person may need a more substantial transition because their employer is changing the task mix or demand in their field. The choice depends on personal constraints, including income, location, learning time, health, family responsibilities, and available training. A framework about organizational risk is not evidence that a degree, certificate, or career pivot will produce a specific outcome.

Organizations should avoid using a risk profile as a screen for workers or a rationale for staff cuts. NIST does not provide a people-ranking instrument. Exposure estimates describe potential applicability of technology to tasks; adoption describes actual use; displacement concerns employment outcomes. Evidence for one does not prove the others. Even observed use may augment a worker, rearrange duties, increase output, or reduce some tasks without eliminating the job. The result depends on the organization and broader demand, and should be measured rather than assumed.

A useful boundary is this: use AI 600-1 to ask whether a defined use is governed, mapped, measured, and managed. Use task-level work analysis to understand where assistance or automation might fit. Use labor-market data and local employer evidence for questions about demand, hiring, and transitions. Use a person’s actual constraints and goals to choose a next step. These evidence streams can inform each other, but they do not collapse into one score. Naming that boundary prevents a risk category from being misread as a verdict about a career.

Sources: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile; Generative AI and jobs: A 2025 update

What should a worker or manager do with the profile next?

For one workplace use, write a short record answering five questions: what task is supported; what information and people are involved; what could go wrong here; what evidence and review will catch or reduce it; and who reopens the decision after a change or incident. Start with a low-consequence, clearly bounded use if a pilot is appropriate, and measure the whole workflow, including checking and correction. If the organization cannot explain the data path, reviewer authority, fallback, or owner, those are concrete gaps to resolve before expanding reliance.

Workers can ask their manager which uses are approved, what information is allowed, what they remain responsible for checking, and how to report a recurring error. Managers can name an owner, involve people who perform and are affected by the work, and document what evidence would cause a restriction or pause. Neither needs to turn AI 600-1 into a certification project. Its value is a disciplined conversation connected to a real task and a decision that can be revisited.

The verdict is therefore practical and limited: prefer a use-specific, lifecycle process over blanket confidence or a blanket rule when the organization can assess the use responsibly. A ban may be justified where risks cannot be controlled or legal obligations prohibit use; broad approval may be reasonable for a narrow, low-consequence task with adequate safeguards. AI 600-1 does not choose between these outcomes. It asks the organization to make its reasoning visible and manage what follows. For an individual deciding how work may change, inspect the task bundle and local evidence before making an expensive career move.

Sources: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile; NIST AI RMF Playbook; AI Risk Management Framework

Questions readers ask