{"resourceId":"nist-genai-profile","versions":[{"version":"legacy/2026-08-29/nist-genai-profile","resource":{"id":"nist-genai-profile","title":"Generative AI risk profile emphasizes testing, provenance, and incident disclosure","organization":"U.S. National Institute of Standards and Technology","sector":"Cross-sector standards and risk management","geography":"United States","publishedAt":"July 26, 2024","sourceName":"Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile","sourceLabel":"NIST AI 600-1","sourceUrl":"https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf","evidenceClass":"standards-guidance","outcomeClass":"emerging","topics":["infrastructure","data-security","governance-procurement","accessibility-workforce","operating-model"],"finding":"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.","sledRelevance":"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":"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.","architectureImplications":"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.","governanceImplications":"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.","securityPrivacyImplications":"Include adversarial testing, prompt and output abuse scenarios, disclosure pathways, access control, data provenance, privacy evaluation, and evidence preservation for incident analysis.","caveats":"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."}},{"version":"enrichment/2026-09-05T02:33:27.019Z/nist-genai-profile","resource":{"id":"nist-genai-profile","title":"Generative AI risk profile emphasizes testing, provenance, and incident disclosure","organization":"U.S. National Institute of Standards and Technology","sector":"Cross-sector standards and risk management","geography":"United States","publishedAt":"July 26, 2024","publicationDate":"2024-07-26","eventDate":null,"sourceName":"Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile","sourceLabel":"NIST AI 600-1","sourceUrl":"https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf","evidenceClass":"standards-guidance","outcomeClass":"emerging","topics":["infrastructure","data-security","governance-procurement","accessibility-workforce","operating-model"],"finding":"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.","sledRelevance":"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":"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.","architectureImplications":"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.","governanceImplications":"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.","securityPrivacyImplications":"Include adversarial testing, prompt and output abuse scenarios, disclosure pathways, access control, data provenance, privacy evaluation, and evidence preservation for incident analysis.","caveats":"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.","streamIds":["state-government","local-government","campus-operations","k12"],"roles":{"sales":"Interpretation — 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.","engineering":"Interpretation — 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":"Interpretation — 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."},"retrievedAt":null,"enrichedAt":"2026-09-05T02:33:27.019Z","enrichmentBasis":"archived evidence"}}]}