MANAGE-3.1: AI risks and benefits from third-party resources are regularly monitored, and risk controls are applied and documented.

MANAGE-3.1 requires you to continuously oversee AI-related risks and benefits that come from third-party resources (models, APIs, data, tools, cloud services), then apply, operate, and document risk controls based on what you observe. Operationalize it by inventorying third-party AI dependencies, defining monitoring triggers and cadence, assigning owners, and keeping audit-ready evidence of decisions and control operation. ¹

Key takeaways:

• Maintain a living inventory of third-party AI resources and the AI systems they affect, with clear owners and review triggers. ¹
• Monitor for third-party changes and emerging issues, then adjust controls (technical, contractual, process) and document the rationale. ¹
• Evidence matters as much as intent: retain logs, review notes, control mappings, and change records that show ongoing monitoring and control operation. ¹

Third-party AI resources move faster than most governance cycles. A model provider updates weights, a SaaS feature silently changes an output behavior, a dataset license changes, or a cloud service introduces a new retention default. MANAGE-3.1 is the control that prevents your AI risk posture from drifting out of date. The requirement is narrow and operational: regularly monitor third-party AI risks and benefits, apply risk controls, and document both the monitoring and the controls. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat “third-party AI resources” as part of third-party due diligence plus ongoing monitoring, with AI-specific signals added: model/version changes, safety policy updates, security notices, performance regressions, bias reports, data provenance changes, and contractual changes that affect permitted use. Your goal is defensibility. You want to be able to show, on demand, what third parties you depend on for AI, how you watch them, what you do when something changes, and where that is documented. ¹

This page gives requirement-level implementation guidance you can assign to control owners and put into a GRC test plan.

Regulatory text

Excerpt: “AI risks and benefits from third-party resources are regularly monitored, and risk controls are applied and documented.” ¹

What the operator must do:

1. Identify third-party resources that meaningfully affect AI outcomes or AI risk (not only “AI vendors,” but also data providers, model marketplaces, cloud AI services, annotation shops, evaluation tool vendors, and embedded AI features in standard SaaS). ¹
2. Monitor those third parties on a recurring basis and when triggering events occur, so you detect changes that could affect risk or realized benefit. ¹
3. Apply risk controls when monitoring reveals issues or when the inherent risk requires it, and keep records that prove the controls were selected, approved, and operating. ¹

Plain-English interpretation

If your AI system depends on a third party, your risk assessment cannot be “one and done.” You need a repeatable way to watch for third-party changes and issues, then respond with controls you can explain and prove.

“Benefits” is not fluff. It means you should also monitor whether the third party is still delivering the intended value (accuracy, latency, user outcomes, operational efficiency) because benefit shortfalls often drive risky workarounds, shadow deployments, and unapproved model swaps.

Who it applies to (entity and operational context)

Applies to: Organizations developing or deploying AI systems that incorporate third-party resources. ¹

Operational contexts where MANAGE-3.1 shows up immediately:

• You call a hosted model/API (LLM, OCR, speech-to-text, moderation, vision).
• You deploy a third-party model artifact internally (open model, vendor model, marketplace model).
• You use third-party datasets for training, fine-tuning, retrieval-augmented generation, or evaluation.
• You depend on third-party tooling that influences AI outputs (prompt management, guardrails, evaluation platforms, feature stores).
• Your “non-AI” SaaS introduces AI features that process regulated or sensitive data (support chatbots, auto-summarization, call analytics).

Control owners to involve:

• Third-party risk management (TPRM) / vendor management
• Information security / product security
• Data governance / privacy
• Model risk management (where applicable)
• Engineering owner for the AI system
• Legal/procurement for contracting controls

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

Step 1: Build a third-party AI dependency inventory (the “AI bill of materials”)

Create a register that maps AI systems → third-party resources → risk owners. Keep it simple, but complete enough to drive monitoring.

Minimum fields that make the register operational:

• Third party name and service (model API, dataset, tool, cloud service)
• AI system(s) impacted and environment(s) (prod, dev, sandbox)
• Data types processed (customer content, employee data, regulated data, secrets)
• Model/version identifiers (where available) and “change notice” channels
• Criticality tier and inherent risk notes (why it matters)
• Control owner and review owner
• Contract/SLA references and termination/exit plan pointer

Practical tip: Start with procurement and network/API logs to find “shadow” AI dependencies that were never flagged as AI.

Step 2: Define “regular monitoring” in a way you can test

Auditors will ask what “regularly” means in your program. Define it using two mechanisms:

• Cadence-based reviews (scheduled check-ins)
• Event-based triggers (reviews when specific things happen)

Create a monitoring standard that includes:

• What signals you monitor (see Step 3)
• Who monitors them (named role, not a team name)
• Where evidence lands (ticketing system, GRC task, shared drive with controls)
• What constitutes a finding (thresholds, severity levels)
• Required response actions and timelines (your policy decision)

Step 3: Monitor the right signals (risk and benefit)

Use a single “Third-Party AI Monitoring Checklist” per resource. Typical signals:

Risk signals (examples)

• Security advisories, breach notifications, pen test summaries you receive
• Subprocessor changes and data residency changes
• Model behavior changes (output drift, increased hallucinations, safety regressions)
• Policy/ToS changes that affect permitted use, training on your data, retention
• Reliability incidents that force fail-open modes or manual workarounds
• New regulatory or internal policy constraints that make the use case higher risk

Benefit signals (examples)

• Performance metrics relevant to your use case (accuracy, resolution time, false positives)
• Cost variability that changes business justification and pushes teams to swap providers
• User feedback and complaint trends related to AI output quality

How to instrument monitoring

• Subscribe to vendor security bulletins, status pages, and policy change notifications.
• Require release notes and model/version disclosures in the contract where feasible.
• Implement technical telemetry: error rates, output sampling, safety filter hit rates, and escalation rates tied to the third-party component.
• Add procurement triggers: any renewal, scope increase, or new data type triggers reassessment.

Step 4: Apply risk controls (technical, contractual, and process)

When monitoring reveals risk, apply controls that match the failure mode. Common control patterns:

Contractual controls

• Notice periods for material changes (policy, subprocessors, model versions)
• Data use limitations (no training on your data unless explicitly approved)
• Audit/attestation rights where feasible
• Incident notification obligations and cooperation clauses
• Service-level commitments for availability and support responsiveness
• Termination assistance and data deletion certification

Technical controls

• Data minimization and redaction before sending to third-party APIs
• Token/secret management, least privilege, network egress controls
• Output guardrails: policy filters, allowed actions, restricted content handling
• Model/output monitoring: drift detection, sampling-based QA, human review gates
• Kill switch / fallback mode when the third-party component degrades

Process controls

• Change management: require an AI impact assessment when a third party changes materially
• Approval workflow for switching models/providers
• Exception process with compensating controls and expiration dates
• Periodic tabletop exercises for third-party AI outages or safety regressions

Step 5: Document decisions and prove ongoing operation

Documentation needs to show a chain:

1. you knew the dependency existed,
2. you monitored it,
3. you found something (or confirmed status),
4. you applied or confirmed controls,
5. you tracked completion and residual risk.

A clean way to do this is a recurring “MANAGE-3.1 control task” per critical third party that attaches evidence artifacts each cycle.

Where Daydream fits naturally: Daydream can track third-party AI dependencies, assign control owners, schedule recurring evidence collection, and keep a single audit trail tying monitoring results to control updates and approvals. That mapping is the fastest way to avoid “we do this in Slack” as your only proof.

Required evidence and artifacts to retain

Keep evidence in a format that survives personnel changes and tool migrations.

Minimum evidence set

• Third-party AI dependency register (current and prior versions)
• Monitoring procedure/standard for third-party AI resources (what you monitor and how)
• Recurring review records (tickets, GRC tasks, meeting notes, sign-offs)
• Copies/links to third-party notices reviewed (status incidents, policy changes, release notes)
• Risk assessments and reassessments triggered by monitoring events
• Control implementation evidence:
  • Contract addenda / DPA / security addendum excerpts (as permitted)
  • Technical configuration screenshots or policy-as-code snippets
  • Monitoring dashboards snapshots or exports
  • Change management approvals and deployment records
• Exceptions log with compensating controls and expiration dates

Evidence quality checks auditors expect

• Dated artifacts
• Named owners/approvers
• Traceability to specific AI systems and third parties
• Clear linkage between findings and actions taken

Common exam/audit questions and hangups

“Show me your universe.” Do you have a complete list of third-party AI resources, including embedded AI features in general SaaS?

“Define ‘regularly.’” Is there a documented cadence and trigger set, or is it informal?

“Prove you monitor.” Can you show review tickets, alerts, meeting records, and what was checked?

“What changed since last time?” Can you show how you detect vendor model/version/policy changes?

“Where are the controls?” Are controls actually implemented (technical/contractual), or only described in a risk assessment?

“Who owns it?” Is responsibility assigned to a person/role with accountability?

Frequent implementation mistakes and how to avoid them

1. Treating onboarding due diligence as monitoring. Fix: separate “initial assessment” from “ongoing monitoring” with recurring tasks and triggers.
2. Monitoring only security posture. Fix: include AI behavior changes (drift, safety regressions) and benefit metrics tied to the business case.
3. No binding change-notification expectations. Fix: add contractual notice obligations and route notices to a monitored inbox or ticket queue.
4. Undocumented control operation. Fix: store evidence each cycle; if it isn’t retained, assume it didn’t happen.
5. Inventory misses embedded AI. Fix: require product owners to attest whether their SaaS includes AI features that process sensitive data, and reconcile with procurement records.

Enforcement context and risk implications

No public enforcement case sources were provided for this requirement in the source catalog, so this page does not cite specific cases.

Risk exposure is still concrete:

• Third-party changes can introduce privacy violations, security incidents, or harmful outputs without any code change on your side.
• If you cannot prove monitoring and control operation, you will struggle to defend model/provider choices after an incident, customer complaint, or regulator inquiry. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and ownership)

• Stand up the third-party AI dependency register for highest-impact AI systems first.
• Assign an accountable owner per critical third party and per AI system.
• Publish a one-page monitoring standard: cadence, triggers, evidence location, escalation path. ¹

Days 31–60 (make monitoring real)

• Turn monitoring into recurring tickets/tasks with required attachments.
• Implement notification routing (security bulletins, status pages, ToS changes) into a triage queue.
• Add minimum technical telemetry for third-party model/API performance and safety outcomes where you have access.
• Update contracts at renewal: change notice, data use limits, incident notification, subprocessors.

Days 61–90 (close gaps and harden controls)

• Run at least one monitoring cycle end-to-end for each critical third party and record results.
• Execute a tabletop for one third-party AI failure scenario (outage, unsafe outputs, policy change) and update playbooks.
• Review exceptions and force expirations or compensating controls.
• Prepare an audit packet: register export, last review artifacts, sample evidence, and control mapping to MANAGE-3.1. ¹

Frequently Asked Questions

What counts as a “third-party resource” under MANAGE-3.1?

Any external component that affects AI behavior or outcomes: hosted model APIs, externally sourced models, datasets, labeling services, evaluation tools, and SaaS with embedded AI features. Track them if their failure or change would change your AI risk posture. ¹

How do I define “regular monitoring” without overengineering it?

Document a cadence plus event triggers, then enforce it with recurring tasks and required evidence attachments. Pick a cadence you can sustain, and increase frequency for higher-risk third parties based on your own risk tiering. ¹

We can’t get model version transparency from a provider. What do we do?

Treat reduced transparency as higher inherent risk and compensate with stronger output monitoring, tighter data controls, and contractual change-notice language where possible. Document the limitation, your compensating controls, and the approval decision.

Does this requirement apply if we only use AI in a “non-production” pilot?

Yes if the pilot uses real data, real users, or outputs that influence decisions. Scale the controls to the pilot’s risk, but still keep an inventory entry, monitoring triggers, and documented controls.

What evidence is most persuasive in an audit?

A traceable chain from inventory entry to recurring monitoring records to applied controls and approvals. Review tickets with attachments (vendor notices, dashboards, change records) tend to land well because they show operation over time.

How should we handle open-source models or datasets where there is no vendor relationship?

Treat the maintainer/community as the third-party source and monitor release notes, vulnerability disclosures, licensing changes, and repository activity. Your controls often shift from contractual to technical and process controls, plus stricter provenance and integrity checks.

Footnotes

1. NIST AI RMF Core