An AI governance checklist for asset managers moving from pilot to production

An AI policy can establish principles, but it does not make an AI workflow safe or dependable. Production governance becomes real when the policy is translated into access rules, approved sources, evaluations, review gates, logs, exception handling, and accountable owners inside the implementation.

For an asset manager, the control design depends on the work. An internal product-knowledge assistant, an RFP drafting workflow, a wholesaler meeting brief, and an automated data-quality agent do not carry the same information, communication, or action risk. Governance should therefore be applied at the workflow level rather than reduced to a single firmwide approval.

This checklist begins after a candidate workflow has been identified and focuses on its control environment. The companion guide to making AI actionable covers opportunity selection, integration, adoption, and the path from output to business action.

Define the workflow and its decision boundary

Document the user, business purpose, trigger, approved inputs, expected output, downstream action, and accountable owner. State whether the system retrieves, summarizes, recommends, drafts, classifies, calculates, or acts. A workflow that only proposes a CRM update has a different decision boundary from one permitted to write directly to a system of record.

• What business decision or action does the output support?
• Who is permitted to initiate the workflow?
• Who reviews or owns the result?
• Which actions are prohibited or always require approval?
• What happens when the system is uncertain or unavailable?

Classify the information before connecting it

Identify every source the workflow may access: prospectuses, factsheets, commentary, CRM records, pipeline data, advisor intelligence, research, investment information, policies, emails, call notes, or third-party data. Classify the information according to the firm’s existing privacy, confidentiality, cybersecurity, vendor, and recordkeeping requirements.

The implementation should preserve source permissions. Retrieval should not allow a user to discover content they could not access in the underlying repository. Prompts, outputs, logs, and evaluation data also need an explicit retention and access model.

Establish approved sources and freshness rules

Firm-specific answers should be grounded in authoritative content or structured data. Record the owner, approval status, effective date, expiration or superseded state, intended audience, and permitted uses for each source class.

Freshness is particularly important for product material, performance, holdings, disclosures, personnel affiliations, and opportunity information. A response can be factually grounded in a document and still be wrong for the current period if the document is stale.

Control models, vendors, and data movement

Document the model and service provider, hosting arrangement, data-processing terms, training and retention settings, subprocessors, geographic considerations, and security controls. Define which model classes are approved for which information classifications and use cases.

If the workflow uses retrieval, tools, plug-ins, or agents, diagram where information moves. A model endpoint may be only one part of the path; search indexes, observability systems, caches, integration services, and human-review applications can also store or expose information.

Build evaluations before broad release

Create a test set that represents normal work and foreseeable failure conditions. Include outdated sources, conflicting documents, missing context, ambiguous names, restricted information, adversarial instructions, unsupported requests, and questions the system should decline.

Score the full workflow for grounding, completeness, permission behavior, required disclosures, format, prohibited content, correct tool use, escalation, and downstream record accuracy. Store evaluation versions so a model, prompt, retrieval, or source change can be compared with the approved baseline.

Place human review where consequences require it

Define when a person must approve an output before it is published, transmitted, or written to a material system. External communications, product information, diligence responses, investment-related content, and consequential CRM or data updates may require different reviewers.

Review should be usable, not ceremonial. Show citations, changed fields, confidence or exception signals, and the proposed action in one place. Capture approval, rejection, edits, and escalation so the workflow can be improved.

Log the events needed for oversight

Useful logs may include the user, workflow version, model, source identifiers, tools called, structured result, review decision, downstream action, error, and timestamp. Avoid placing sensitive content in logs by default. Define who can inspect logs and how long each record type should remain available.

Assign operational ownership

Every production workflow needs a business owner and a technical owner. The business owner is accountable for the intended use, source approval, review process, and outcome. The technical owner is accountable for availability, configuration, monitoring, access, change control, and incident response. Legal, compliance, privacy, cybersecurity, model-risk, or vendor-management functions should be involved according to the firm’s requirements.

Measure adoption, quality, and business impact

Usage alone does not establish value. Track the baseline process and the intended improvement: preparation time, response time, throughput, review effort, correction rate, acceptance rate, exception rate, or influenced opportunity activity. Monitor quality and business outcomes together; a faster process that creates more corrections is not an improvement.

Production-readiness checklist

• Workflow, users, purpose, outputs, actions, and owners are documented.
• Information classifications and source permissions are enforced.
• Approved-source, freshness, and superseded-content rules are defined.
• Model, vendor, data-flow, retention, and security decisions are approved.
• Normal, edge, restricted, and failure cases have been evaluated.
• Human-review and escalation gates are implemented where required.
• Logs support investigation without unnecessarily duplicating sensitive data.
• Changes to models, prompts, tools, and sources follow versioned release controls.
• Quality, adoption, exceptions, and business impact have measurable baselines.
• Incident, rollback, and workflow-disable procedures are understood.

This checklist is an implementation framework, not legal or compliance advice. Each asset manager should determine the requirements that apply to its organization, products, data, communications, and jurisdictions. Explore AUMOps applied AI services, review a representative product-knowledge assistant design, or apply the controls to an RFP and DDQ workflow.