MANAGE-1.1: A determination is made as to whether the AI system achieves its intended purposes and stated objectives and whether its development or deployment should proceed.

MANAGE-1.1: a determination is made as to whether the AI system achieves its intended purposes and stated objectives and whether its development or deployment should proceed. requirement is a governance gate, not a philosophy statement. If you cannot show what the system is supposed to do, how you tested it, and who decided to proceed, you will struggle to defend the deployment internally (risk committee, audit) and externally (customers, regulators, litigants).

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat MANAGE-1.1 like a control with three parts: (1) defined objectives and intended use, (2) evidence-based evaluation against those objectives, and (3) an explicit decision with accountable sign-off and enforced release gating. The NIST AI Risk Management Framework positions this as part of managing AI risks across the lifecycle, which means the “determination” should recur when models change, data shifts, or the use case expands. ¹

This page gives you requirement-level implementation guidance you can put into a control library, map to an SDLC/MLLC, and audit quickly.

Regulatory text

Text (MANAGE-1.1): “A determination is made as to whether the AI system achieves its intended purposes and stated objectives and whether its development or deployment should proceed.” ²

What the operator must do:
You must make a documented decision, based on defined objectives and evaluation results, about whether to proceed with development or deployment. The determination needs to be traceable to the system’s intended purpose and stated objectives, and it needs to happen before the system is released or meaningfully expanded into production use. ²

Plain-English interpretation

• “Intended purpose” means the concrete job the AI system is supposed to perform in a specific workflow for a defined user group, under defined constraints.
• “Stated objectives” means the measurable targets you expect the system to meet (performance, reliability, safety, fairness, privacy, security, explainability, operational resilience), with thresholds appropriate to the use case.
• “Determination” means a real gate: proceed, proceed with conditions, hold pending remediation, or stop. It is not satisfied by an informal Slack message or a model card that never ties back to approval.

Who it applies to

Entity scope: Any organization developing, procuring, integrating, or deploying AI systems, including AI-enabled features embedded in broader products and workflows. ²

Operational contexts where this shows up immediately:

• You build models internally and push them to production.
• You fine-tune or configure third-party foundation models for internal or customer-facing use.
• You buy an AI product and integrate it into a business process (for example, fraud, HR screening, customer support, underwriting, security triage).
• You materially change an existing model (new training data, new objective, new user population, new automation level).

What you actually need to do (step-by-step)

1) Define the decision scope and the “intended purpose”

Create a one-page Intended Use & Objectives Statement that is specific enough to test. Include:

• Business process and user(s)
• In-scope decisions the AI will influence or make
• Out-of-scope uses (explicitly prohibited)
• Required human oversight points (where humans must review, override, or approve)
• Harm assumptions (who can be impacted and how)

Practical tip: If you cannot describe the intended purpose without referencing the model type (“LLM chatbot”), you are not ready for MANAGE-1.1.

2) Convert objectives into acceptance criteria

For each objective, define measurable acceptance criteria and the evidence source. Cover at least:

• Functional performance (task success measures that reflect real use)
• Safety and misuse resistance (what “unsafe output” means for your domain)
• Reliability and resilience (how the system behaves under stress, edge cases, outages)
• Privacy and security (data handling, access control, prompt injection threats where relevant)
• Fairness and bias (where protected classes or sensitive outcomes are implicated)
• Transparency (user disclosures, logging, traceability, explanations appropriate to use)

Write criteria so an auditor can tell pass/fail. If you cannot write it as pass/fail, write it as “pass / conditional pass / fail” with defined conditions.

3) Plan the evaluation (before you run it)

Create an AI Evaluation Plan tied to the objectives, including:

• Test datasets and their provenance (including representativeness limitations)
• Offline evaluation methods (benchmarks, back-testing, red teaming where relevant)
• Online evaluation methods (pilot, shadow mode, A/B test) if applicable
• Sign-off roles and independence expectations (who can’t approve their own work)
• Pre-defined decision options and escalation paths

This is where GRC should insist on “pre-commitment”: define what success looks like before you see results.

4) Execute testing and compile results into a decision packet

Run the planned evaluations and compile an AI Go/No-Go Decision Packet:

• Objective-by-objective results mapped to acceptance criteria
• Known limitations and residual risks
• Mitigations and controls (human-in-the-loop, rate limits, monitoring, guardrails, policy constraints)
• Release scope (who gets access, geographies, user segments)
• Conditions for launch (required fixes, monitoring thresholds, rollback plan)

5) Hold a formal decision meeting and record the determination

Run an AI Risk/Release Review with documented attendance and decision authority. Record:

• Decision: proceed / proceed with conditions / hold / stop
• Rationale tied to objectives and evidence
• Conditions and deadlines (if conditional)
• Named accountable owners for remediation and post-deploy monitoring
• Exceptions granted (if any), with compensating controls

6) Enforce gating in your delivery process

MANAGE-1.1 fails in practice when the decision exists but does not block release. Put a hard gate in:

• Change management (CAB) for production deployments
• MLOps release pipeline (cannot promote model without approval artifact ID)
• Procurement intake for third-party AI (cannot enable feature in production without decision packet)

If your organization uses Daydream, treat this as a control mapped to a workflow: intake → objective definition → evaluation plan → evidence upload → approval → recurring review tasks.

7) Reassess when the system changes (or the environment does)

Repeat the determination when:

• Model version changes materially
• Training data sources change
• Intended use expands
• Performance drift or incidents indicate objectives are no longer met

NIST frames this as lifecycle risk management, so you should expect recurrence, not a one-time launch ritual. ³

Required evidence and artifacts to retain

Retain artifacts in a system-of-record that supports audit retrieval:

Artifact	Minimum contents	Owner
Intended Use & Objectives Statement	purpose, users, in/out of scope, oversight, constraints	Product + Compliance
Acceptance Criteria Register	objective, metric/threshold, test method, data source	Model owner + Risk
AI Evaluation Plan	test design, datasets, roles, decision options	Engineering + Risk
Evaluation Results Report	results mapped to criteria, limitations, mitigations	Engineering/DS
Go/No-Go Decision Record	decision, rationale, approvers, conditions, date	Compliance/GRC
Release Gate Evidence	ticket IDs, pipeline controls, CAB minutes	IT/Release Mgmt
Exception Register	exceptions, compensating controls, expiry	Compliance
Post-Deploy Monitoring Plan	what you monitor, triggers, rollback	Ops/ML Ops

Common exam/audit questions and hangups

Auditors and internal risk committees commonly press on:

• “Show me the stated objectives and where they were approved.”
• “How do you know the model meets its intended purpose in real workflows, not just in a lab test?”
• “Who can approve a launch, and can developers approve their own system?”
• “Where is the release gate enforced?”
• “What happens when you change the model or expand the use case?”
• “Show decisions for third-party AI tools too, not only internally built models.”

Hangup to anticipate: teams present a model card or risk assessment that does not end with an explicit proceed/hold/stop determination.

Frequent implementation mistakes (and how to avoid them)

1. Objectives written as marketing language
   Fix: require measurable acceptance criteria and a pass/fail determination.

2. No separation between evaluation and approval
   Fix: define decision authority (risk, compliance, product) and document conflicts of interest.

3. The decision is made after deployment
   Fix: add a release gate that requires the decision record ID before production access.

4. Only performance is evaluated
   Fix: ensure objectives include safety, security, privacy, and operational constraints relevant to the use case.

5. Third-party AI is treated as “someone else’s problem”
   Fix: require the same decision packet for externally sourced AI, adjusted for what you can test and what you must obtain contractually.

Enforcement context and risk implications

NIST AI RMF is a framework, not a regulator, so MANAGE-1.1 is typically tested through customer due diligence, internal audit, and contractual commitments rather than direct NIST enforcement. The practical risk is defensibility: if an incident occurs (harmful output, discrimination allegations, privacy breach, security exploit), your ability to show a pre-deployment determination tied to objectives becomes a central governance fact pattern. ²

A practical 30/60/90-day execution plan

First 30 days (stand up the gate)

• Name a control owner for MANAGE-1.1 and document RACI (Product, Engineering, Risk, Compliance, IT).
• Create templates: Intended Use & Objectives, Acceptance Criteria Register, Decision Record.
• Pick the gating mechanism (CAB ticket, MLOps approval, procurement checklist) and make it mandatory for new AI deployments.

Days 31–60 (run it on real systems)

• Inventory AI systems in scope and select the first set for review (start with customer-impacting or high-consequence workflows).
• Run evaluation planning and produce decision packets for those systems.
• Hold the first formal go/no-go reviews and record determinations with conditions and owners.

Days 61–90 (make it repeatable)

• Add recurring triggers: model change, new data source, expanded use case, incident, drift.
• Train engineering and product on how to write objectives and acceptance criteria that pass review.
• Centralize evidence retention and reporting (a GRC workflow tool such as Daydream can reduce the “where is the artifact?” scramble during audits).

Frequently Asked Questions

Does MANAGE-1.1 require a single metric to determine success?

No. You need a determination tied to the system’s intended purpose and stated objectives, which usually requires multiple acceptance criteria across performance, safety, and operational constraints. ²

How do we apply this to a third-party AI feature we didn’t build?

Define your intended purpose and objectives for the business process, then test what you can (configuration, prompts, integration behavior) and document what you rely on the third party to provide (assurances, audit reports, contractual controls). You still need a go/no-go determination for deployment in your environment. ²

Who should sign the “proceed” decision?

Assign decision authority based on risk and accountability: the business owner should accept residual risk, and Compliance/Risk should confirm the evidence meets the acceptance criteria and that gating occurred. Avoid allowing the model developer to be the sole approver.

What qualifies as “stated objectives” if the project is exploratory?

Set objectives appropriate to the phase: pilot objectives can focus on bounded scope, strict human review, and clear stop conditions. Document that the objectives are pilot-specific and prohibit production expansion without a new determination. ²

How often do we need to redo the determination?

Redo it when changes could affect whether objectives are met: material model updates, new training data, new user population, automation level changes, or incidents and drift that undermine prior results. NIST expects lifecycle management rather than one-time assessment. ³

What’s the minimum evidence set to satisfy auditors quickly?

Keep the objectives statement, acceptance criteria, evaluation results mapped to criteria, the signed decision record, and proof of a release gate that prevented deployment before approval. Auditors care more about traceability and timing than document volume.

Footnotes

1. NIST AI RMF Core; Source: NIST AI RMF program page

2. NIST AI RMF Core

3. NIST AI RMF program page