From the SLED-wide archive edition of August 29, 2026
Generative AI risk profile emphasizes testing, provenance, and incident disclosure
U.S. National Institute of Standards and Technology · Cross-sector standards and risk management · United States
- Publisher
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
- Original publication
- July 26, 2024
- Source retrieved
- Not recorded in the historical archive
What happened
NIST's cross-sector profile extends the AI Risk Management Framework with risks and suggested actions tailored to generative AI across design, deployment, operation, and decommissioning.
Why it matters
The profile gives SLED assurance teams a common control vocabulary for procurements, pilots, internal assistants, and public services even when departments use different vendors or deployment models.
Evidence and measured results
The profile organizes actions under Govern, Map, Measure, and Manage and gives special attention to governance, content provenance, pre-deployment testing, and incident disclosure. It distinguishes model, application, organizational, and ecosystem risks and stresses tailoring controls to use-case context.
Limitations and uncertainty
The profile is voluntary, cross-sector guidance rather than a certification or outcome study; not every action applies to every actor, and organizations must tailor it to law, risk tolerance, resources, and local context.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source as summarized in the preserved archive. Enriched 2026-09-05; this does not change the original publication date. Labels below come from the analysis itself.
Sales
Role takeaway
- Customer problem
- departments using different AI products need a shared way to discuss risk and evidence without an unmanageable generic checklist.
- Stakeholders
- risk, security, privacy, procurement, service owners, and enterprise architecture.
- Discovery
- what harm matters in this use case; which actors control it; what evidence exists; and what triggers renewed testing?
- Value hypothesis
- tailored Govern, Map, Measure, and Manage actions may make assurance decisions clearer.
- Potential engagement
- map one proposed or operating service to applicable actions and an evidence plan.
- Unsupported claims
- this voluntary cross-sector profile is neither certification nor an outcome study; adopting its vocabulary does not prove compliance, system safety, or elimination of risk.
Pre-sales engineering
Role takeaway
- Fit
- apply the profile to the complete application, including retrieval, prompts, data, users, and operating dependencies.
- Architecture and integration
- include evaluation, red-teaming, content provenance, version documentation, logs, monitoring, incident response, and decommissioning in the existing service architecture.
- Prerequisites
- system boundaries, accountable actors, use-case risk context, and available evidence.
- Constraints
- not every action applies to every organization or component, so document relevance instead of implementing everything mechanically.
- Security
- test adversarial prompts and output abuse, access and disclosure paths, privacy behavior, and evidence preservation.
- Proposed validation
- build a risk-to-control-to-test mapping for the service, then change a model, prompt, or source and demonstrate that relevant evaluations and approval records are updated.
Delivery
Role takeaway
- Work
- select applicable actions, assign evidence owners, integrate tests and incident handling, and document decommissioning responsibilities.
- Dependencies
- service context, risk tolerance, legal interpretation, and teams able to operate the chosen controls.
- Ownership
- the service owner accepts residual risk; security/privacy and engineering own their measures; procurement addresses supplier evidence and change notice.
- Skills and adoption
- train reviewers to tailor the profile and explain excluded actions instead of treating it as a certification checklist.
- Governance checkpoints
- initial mapping, predeployment review, material changes, incidents, and retirement.
- Proposed acceptance
- each selected action has evidence and an accountable owner, exceptions are justified, and a change/incident exercise demonstrates updated review. Risks include checkbox assurance and controls chosen without resources to sustain them.
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Build evaluation, red-teaming, provenance, logging, version documentation, monitoring, incident response, and decommissioning into the service architecture; test the complete application and retrieval context, not only the base model.
Governance
Who approves, reviews and stays accountable for outcomes?
Map selected actions to use-case risk and accountable actors, document why controls apply or do not, and require updated testing when models, system prompts, data sources, or user populations change.
Security and privacy
What data, permissions and controls need testing?
Include adversarial testing, prompt and output abuse scenarios, disclosure pathways, access control, data provenance, privacy evaluation, and evidence preservation for incident analysis.
The preserved archive analysis covered architecture, governance and security. Not assessed for this record: accessibility and workforce, procurement, operating model.
Publication history
- 2026-08-29SLED-wide archive · Issue 0214 resources
Stable resource ID: nist-genai-profile