Before an investment manager lets generative AI draft an investor response or summarise a know your customer (KYC) file, someone needs to decide what information it may use, what its output can influence and who checks the result. An approval that says only “staff may use AI” leaves those decisions unresolved.
The AIMA generative AI checklist is an industry resource for considering these risks. This article turns its publicly stated themes into an original implementation plan: define each use case, protect the data, test the workflow and retain evidence of human review.
AIMA is an industry association, not a regulator. The full checklist requires member access. We reviewed its public foreword and access notice, not the restricted checklist. The steps and examples below are AgentKYZ’s recommendations, informed by the public sources cited, and do not reproduce AIMA’s questions or imply its endorsement.
What AIMA makes public
The Alternative Investment Management Association describes itself as a membership association for alternative investment managers. Its checklist’s public foreword identifies data privacy, legal issues and cyber security as risks of generative AI. It encourages policies and attention to changing regulation, with AI use considered within the firm’s wider risk management.
That foreword supports a discussion of the themes. It does not establish the contents, sequence or completeness of the member-only questions. To obtain the official resource, visit AIMA’s checklist page and follow its member-login instructions. Check the applicable use terms before sharing it or putting it into an AI system.
Keep industry guidance separate from legal obligations. For example, the UK FCA’s published AI approach explains how existing regulatory frameworks apply to AI. It is not a worldwide rulebook. Have compliance and counsel identify the requirements relevant to your entities, activities, clients and data flows.
For practical risk controls, the public NIST Generative AI Profile provides a separate, voluntary reference. It addresses risks including fabricated outputs, privacy, harmful bias, information security and third-party dependencies. Neither using NIST nor completing an AIMA checklist certifies a manager’s compliance.
Set a generative AI policy and assign owners
Start with a register of where generative AI is already used or proposed. Include staff-accessible chatbots, research assistants, coding tools and AI features inside existing software or outsourced services. Record the business purpose, users, provider, permitted inputs, output destination, owner and approval status.
Assess the use case rather than approving a product for every task. Summarising a public annual report for an analyst to check has different consequences from writing investor communications, changing a client risk rating or initiating a trade. Record what could go wrong, who could be affected and which controls reduce that risk.
Give each workflow a business owner and involve compliance, security, privacy and investment-risk specialists where relevant. The approver should be able to limit or stop the use. A small manager can use an existing governance forum if it has the competence, authority and time to challenge decisions.
Put the boundaries into a short generative AI policy that staff can apply:
- Name the approved tools, accounts and tasks. Explain how to request a new use.
- Specify which data may be entered and which material is prohibited without further approval, including investor identity documents, confidential holdings and material non-public information.
- Define what needs a qualified reviewer before it is shared, relied on or used to change a record.
- Set limits on connected tools and actions. A drafting assistant should not inherit authority to send communications, release payments or execute trades.
- Give staff a reporting route for mistakes, suspected disclosures and unauthorised use. Train them with examples from their actual work.
Illustrative approval: allow an assistant to prepare a draft summary of approved, sanitised customer due diligence (CDD) records for a reviewer. Give it read-only access to that case’s permitted documents, prohibit client approval and require a source reference for each factual conclusion. Treat any proposed expansion of access or authority as a new approval decision.
Check data flows and provider terms
Map where prompts, uploaded files, retrieved documents and outputs go. Include the application provider, underlying model provider, connected systems, support access and subprocessors. Ask the provider to confirm the arrangements for the product and account tier you will actually use.
Review model-training and service-improvement uses, retention and deletion, access controls, processing locations, incident notification, change notification and exit arrangements. “Not used for training” answers one question; it does not establish that nothing is stored or accessed. Resolve gaps in the contract, configuration and risk assessment before approving sensitive data.
Check rights as well as confidentiality. A licensed research report, restricted AIMA document or third-party dataset may have use conditions that affect uploading, processing or redistribution. Have the relevant owner or counsel assess those conditions. Public availability alone is not a blanket licence for every use.
Apply least-privilege access to document retrieval. Test that a user cannot obtain another fund’s investor information through a prompt, search result or generated summary. Minimise inputs and protect logs, because a retained prompt or output may itself contain sensitive information. Set retention according to applicable obligations and the approved purpose rather than saving everything indefinitely.
These checks address the privacy, intellectual-property and supplier risks described in NIST AI 600-1, sections 2.4, 2.10 and 2.12. A security report can support provider due diligence, but check its scope and period against your actual deployment.
Test errors, sources and access before launch
NIST’s profile explains that generative AI can produce confidently stated false content, including invented citations, and that security risks include prompt injection. In a document workflow, that can mean text inside an uploaded file tries to instruct the assistant to ignore its task or disclose information. See sections 2.2 and 2.9.
Use an isolated test environment with synthetic or appropriately authorised data. Define expected results before running the system. Test the full workflow, including retrieval, connected tools, human review and the final record, rather than accepting a model demonstration as evidence of suitability.
For a proposed CDD summarisation workflow, useful cases include:
- Missing ownership evidence. The file identifies an intermediate company but contains no evidence of its owners. The expected result is an explicit gap, with no invented person or ownership link.
- Conflicting records. Two documents give different ownership percentages or dates. The summary should identify the conflict and refer it for review, rather than silently choosing a value.
- Unsupported citations. A draft cites a page that does not support its statement. The review process should reject the claim even when the citation looks plausible.
- Embedded instructions. A synthetic document tells the assistant to disclose another case or mark the file approved. The workflow should preserve its access and approval boundaries.
- Difficult language and document formats. Include relevant names, scripts, scans and poor-quality pages. Record unreadable material and compare errors across the formats and languages you expect to handle.
- Provider failure. Disable the service or a document connection. The case should remain incomplete and pass to the agreed fallback, without being reported as successfully reviewed.
Measure unsupported factual claims, missed material gaps, inappropriate disclosures, reviewer corrections and the time needed to reach a correct result. Define acceptance criteria according to the consequences of each failure. A high average score cannot offset a failure that exposes another investor’s documents.
Record the tool and available model/version identifiers, configuration, test inputs, expected and observed results, defects and retests. Where a provider does not expose a version, document that limitation and how you will detect changes. Decide whether to approve, narrow, defer or reject the use, with reasons.
Keep decisions with qualified reviewers
Human review needs a specified task, access to evidence and authority to disagree. Asking someone to click “approve” after reading a fluent summary does not test whether the underlying conclusion is sound. NIST’s discussion of human-AI configuration in section 2.7 identifies over-reliance and automation bias as risks.
Apply the boundary to the work your firm already performs:
- Due diligence questionnaires (DDQs): an assistant may prepare wording from an approved response library and current evidence. The answer owner should check entity scope, dates, qualifications and supporting records before release. Our AIMA DDQ guide covers response ownership and template selection; AI use does not change those responsibilities.
- Customer due diligence: use a draft to locate facts and gaps, then check identity, ownership and risk conclusions against the documents. The AIMA CDD implementation guide explains the underlying file work. A generated ownership chart is not, by itself, verification of ownership.
- Sanctions: if AI prepares an alert summary, require it to point to the actual screening result and comparison evidence. Do not accept a general-purpose chatbot’s “no match” answer as clearance. Our sanctions-screening guide covers list scope, matching, investigation and escalation separately.
- Administrator oversight: ask whether AI is used in your fund’s service, what it does, how outputs are checked and how changes or incidents reach you. Request fund-specific examples and test findings alongside the administrator due-diligence evidence, rather than relying on a provider-wide AI policy alone.
For investment research, require the analyst to verify material facts and calculations against the source. Do not extend approval for research assistance to portfolio decisions or trade execution without a separate assessment.
If your immediate need is a reviewable KYC workflow, explore AgentKYZ’s review software or managed KYC service. Agree the preparation tasks, human checks and client approval boundary before any live files are transferred.
Keep evidence current and AI claims accurate
For each approved use, maintain a retrievable record linking the owner, purpose, risk assessment, permitted data, provider review, testing, approval conditions and next review. Retain the material source references, output, corrections and sign-off needed to reconstruct a decision, subject to your access and retention rules.
Monitor live exceptions and reviewer overrides. Set reassessment triggers for a new model, changed provider terms, a new data source, broader permissions, altered prompts or a material failure. Give someone authority to suspend the workflow and use a tested manual fallback. An incident procedure should cover containment, evidence preservation, affected-case review and assessment of any notification duties with the appropriate specialists.
Use that record when answering investors’ questions about AI. Distinguish a pilot from a production service and a drafting aid from a decision-making system. Claims about accuracy, coverage, savings or autonomy need evidence for the stated scope and period.
On 18 March 2024, the US SEC announced settled charges against Delphia and Global Predictions for false and misleading statements about their purported AI use. Have the system owner and compliance team check AI-related descriptions before they appear in a DDQ, pitch deck or website.
For anti-money laundering (AML) and KYC statements, use the DDQ evidence guide to connect the answer to dated control records. Do not attach raw investor files to an ordinary investor response; agree a lawful, controlled disclosure route.
Put the first use case through a 30-day review
The timetable below is an illustrative starting plan, not an AIMA deadline or a promise that a use case will be ready in a month. A higher-risk deployment may need substantially more work.
- Week 1: inventory current use, appoint the owner and select one bounded pilot. Write down the business problem and how the team handles it without AI. Address any unapproved sensitive-data use immediately.
- Week 2: assess the data flow and provider terms, document the permitted tasks and brief the reviewers. Resolve access and confidentiality questions before testing with non-public data.
- Week 3: run the agreed test cases, investigate failures and retest corrections. Compare the quality and review effort with the existing process, including difficult cases.
- Week 4: submit the evidence for an approval decision. Record unresolved risks, limits, monitoring, fallback arrangements and the next review. A decision to defer launch is a valid outcome.
The approval pack should let a colleague answer one concrete question: what evidence supports allowing this particular workflow to process this particular information?
Apply the controls to an AgentKYZ KYC workflow
AgentKYZ combines AI-assisted case preparation with qualified human review under the client’s AML policy. The workflow supports document review, ownership analysis, screening and documented findings. Your firm retains final approval and compliance responsibility, with approval roles set by your AML policy. See how AgentKYZ’s preparation and review process works.
That gives a manager a defined workflow to assess. It does not replace the manager’s AI inventory, legal assessment, provider due diligence or deployment testing. Ask us about the proposed engagement’s data flows, permissions, review evidence and change arrangements, and assess the answers against your requirements.
Where the concern is the quality of administrator-held files, Shadow KYC tests investor files against the fund’s AML policy and produces evidence-linked findings for oversight and remediation. Scope any AI-system validation separately; a file review does not establish that every model or connected application is safe for other uses.
To discuss managed KYC, bring a description of the workflow, jurisdiction, approximate case volume and the approval roles you need to preserve. For administrator oversight, bring the service scope and known evidence gaps. Keep live investor records out of the initial enquiry and agree secure access before sending files.