AI Vendor Due Diligence for Banks: Report Editor Review
Summary
When a reporting vendor adds an AI assistant to its editor, the usual questionnaire question ("does the service use generative AI?") settles nothing. A better review classifies what the feature can change and read, asks five questions about data flow, and tests the controls that keep a design assistant lower risk. A one-page review template is included. For risk, third-party and technology teams at banks.
Consider a third-party risk analyst at a mid-sized bank. The reporting vendor announces that the report editor now has an AI assistant. The bank's vendor questionnaire has a single AI question: does the service use generative AI, yes or no? The vendor answers yes. What happens next depends on who reads the answer. One team treats it as a model and asks for validation evidence that no one can supply, because there is no model output in a client document to validate. Another team ticks a box and moves on, and no one records that the assistant can read the structure of the bank's reports, or that attached files are uploaded to a third-party provider. Both outcomes come from the same cause: the question was too coarse to separate a feature that drafts a template from one that produces a figure.
The regulatory backdrop makes the coarse question more likely, not less. In April 2026 the US federal banking agencies issued revised model risk management guidance, published as SR 26-2, OCC Bulletin 2026-13 and FDIC FIL-15-2026, replacing the 2011 guidance known as SR 11-7. The text states that generative AI and agentic AI models are novel and rapidly evolving and are not within the scope of the guidance. It adds that a banking organisation's own risk management and governance practices should guide the controls applied to tools outside that scope, and the agencies said they plan to issue a request for information on banks' use of AI, including generative AI. The guidance is expected to be most relevant to banks with more than $30 billion in total assets. The OCC bulletin has the full text. Other jurisdictions have their own expectations, and this post uses the US text as an example of a pattern that appears in many places: the feature is not in a dedicated framework, so the review falls to the bank's own third-party and model risk teams.
Start With What the Feature Touches
Before any questionnaire, classify the feature on two axes. The first is what it can change. The second is what it can read.
A report-editor assistant works at design time. A person describes a layout or a change, the assistant makes edits to the template, and a person reviews them. The output is a template, which then goes through whatever change control the bank applies to templates. That is a different risk from a feature that writes the figures or the narrative in a client document at the moment of generation, where nothing sits between the model and the recipient. If the figures in a generated document come from the bank's data sources and the model does not produce them, model risk in the usual sense (a wrong estimate, drift in a score) has little to attach to, and the more relevant questions are about data handling and about the integrity of the template.
Two details keep that classification from being too comfortable. First, "design time" can include data binding. An assistant that can add a table can often also choose which field feeds a column, and may be able to create or change the data sources and parameters behind it. A table that looks right and binds to last month's rate field instead of this month's passes a visual check and produces a wrong document, and a person reviewing layout will not catch it. The review focus for a design assistant is therefore the bindings and the data it was shown, more than the appearance of the output.
Second, what the assistant can read is not limited to the template. Depending on the product, it may be able to see sample or runtime data in the editor, the structure of connected databases, and any files a user attaches. That determines whether using the assistant can send customer information to a third party, and it is the question the five below are built to answer.
Five Questions for Any Vendor
These are questions, not findings. The answer to each should be something the vendor can put in writing and, where possible, point to in documentation.
What can it see? Ask for a list by category, and separate what is sent automatically with each request from what is sent only when the user does something (attaches a file, previews data, asks the assistant to look at a value). Report structure, data source definitions, parameter values, actual data rows, uploaded files and any instructions the bank has configured are different categories with different sensitivity. A vendor that answers "only metadata" should be asked to define metadata.
What leaves, and where does it go? An assistant built on an external model sends something to that provider. The questions are which provider, under whose contract, and where processing takes place. If the bank supplies its own provider credentials, the bank holds the contract with the model provider and inherits that provider's terms, including how long the provider keeps uploaded files and whether inputs are used to improve its models. If the vendor supplies the model, the vendor is in the chain and the bank needs its sub-processor information. Where the reporting workspace is hosted is a separate question from where the model provider processes a request, and answering one does not answer the other.
What is kept, and for how long? Prompts, conversation history, uploaded files, the vendor's own logs and the provider's retention are four different stores with four different clocks. Ask for the retention period of each, who can read them, and whether the bank can delete a conversation or a file and have the deletion pass through to the provider.
Who can use it, and who can switch it off? A feature that is available to every editor by default is a different proposition from one that needs an explicit permission and an explicit configuration. Ask whether it can be disabled for the whole workspace, restricted by role, and whether a user's own access rights limit what the assistant can do on their behalf.
What is recorded? When a design changes, the bank may later need to know who asked the assistant to do what, and what changed as a result. Ask what is logged, who can see it, and how long it is kept. Answers range from a full record of each action to nothing beyond the final template, and the review team needs to know which it is before deciding how much compensating control to build around it.
Controls That Lower the Risk in Practice
Many of the controls that make a design assistant manageable are controls the bank should already have around templates, applied to a faster way of producing them.
Treat the output as a draft. An assistant's edit is a proposal. The template owner reviews the structure and, separately, checks the data bindings against known values. Two gates are worth keeping distinct: does the template have the right sections in the right order, and do the figures it displays match the source?
Keep change control on the template, not on how it was made. A template change needs an approval and a retrievable copy of the previous version whether it was drawn by hand or drafted by an assistant. Faster construction makes this more important, because more changes arrive in less time.
Design with synthetic data. If the assistant can read data shown in the editor, design sessions that use invented clients keep customer information out of the conversation. Reserve production data for testing in a controlled environment, with the permissions that apply there.
Restrict by role. Not everyone who edits reports needs the assistant. Grant it to the template designers and leave it off for report readers and approvers. The same least-privilege logic that applies to editing applies here.
Reconcile before release. Before a new or changed template goes to production, generate documents from known test data and compare the figures against the source system. This is a test of the template, and it catches a wrong binding whoever or whatever introduced it.
A One-Page Review Template
A risk team can reuse this table for any vendor's design assistant. The last column says what should send the review to a senior reviewer.
| Area | Ask | Evidence to request | Escalate if |
|---|---|---|---|
| Scope | What can the assistant change: layout, data sources, parameters, themes? | Product documentation, a demonstration | It can change data sources or parameters and there is no review step before production |
| Input | What does it receive automatically, and what only on request? | A written list by category | The vendor cannot say whether data values are included |
| Provider | Which model providers, whose contract, where processed? | Sub-processor list or provider terms | The bank cannot identify the contract that governs the data |
| Retention | How long are prompts, conversations, files and logs kept, and by whom? | Retention schedule for each store | Any store has no stated period, or deletion does not reach the provider |
| Access | Can it be disabled, and restricted by role? | Configuration guide, role documentation | It is on for all editors by default and cannot be limited |
| Records | What is logged about assistant use and changes? | Log description, sample extract | Nothing records who instructed a change |
| Generation | Is the assistant involved when documents are generated? | Written confirmation | It is, or the vendor will not say |
| Output | How is AI output reviewed before it reaches clients? | The bank's own change procedure | Assistant output can reach production unreviewed |
How This Maps to CxReports
Here is what the CxReports documentation states for each part of the review. Where the documentation is silent, this section says so, because those are the questions to put to the vendor in writing.
Scope. The AI Assistant is a chat inside the Report Editor, and the same AI Integrations also serve the Portal Assistant and optional automatic dictionary translation. In the editor, the assistant can add, update and remove elements and pages, create, update and delete data sources and parameters, and create dictionaries and translation entries. It can inspect themes, but the documented actions do not include editing themes or workspace settings. The assistant's actions appear in the chat as expandable rows so the user can review what it did. Because data sources and parameters are within its reach, the review step that matters is the data binding check described above.
Input. Each message automatically includes an overview of the current report: its pages, elements, data sources, parameters, dictionaries and custom components. On request, the assistant can inspect a data source, a parameter, a dictionary, a custom component, a theme and current runtime data, and can browse workspace languages, external databases and the file system. Users can also attach PNG, JPEG and WebP images, PDFs (not with the DeepSeek integration) and JSON or CSV files, up to three per message. The assistant reads the full text of JSON and CSV files, and when it creates a data source from an attached file, that data source holds the file's exact content. Skills, which are text instructions the workspace configures, are also included in the context, so they are not the place for credentials or customer data.
Provider and processing. The assistant needs an AI Integration, which a workspace administrator configures with an engine (OpenAI, Anthropic, Google or DeepSeek), a model name and the organisation's own API key. Keys are stored encrypted and decrypted only when needed. So the bank selects the model provider, and the provider's terms apply to what is sent. Attached PDFs are uploaded to that provider, which keeps them for a period that depends on the provider; removing a PDF before sending it, or deleting the chat, asks the provider to delete the file. AI Integrations are excluded from Data Export and Import, so each workspace sets up its own. The CxReports workspace itself is hosted either as the CxReports-managed cloud service (EU, US or AU data centres) or self-hosted on premise, and that choice does not change which provider the assistant calls.
Access. The assistant requires the AI permission on the user's role (Read for read-only chat, Full Access for full use) and at least one configured integration. A workspace without an integration has no assistant, and roles without the permission cannot use it. Different integrations can be configured and a user picks one per conversation, so a bank can offer only the integrations its provider review approved.
Retention, records and generation. The documentation covers provider retention of uploaded PDFs and the deletion behaviour above. It does not state how long CxReports keeps conversation content, what assistant use is logged, or who can view such logs, and it does not say whether an assistant action is limited by the user's own Reports and Data Sources permissions. It describes the assistant as an editor tool. Confirm in writing that scheduled and API-driven generation does not involve a model, and obtain the retention and logging answers before relying on any of them in a risk assessment. These are the "Retention", "Records" and "Generation" rows of the template, and they are the ones to fill from the vendor, not from this article.
Controls the product supports. Role-based access limits who can use the assistant. A Report Generation Job can hold deliveries for review, with approval before anything is sent, which fits a bank's release control for documents. Data Export saves a file of the workspace's reports, templates, themes and related configuration, so exporting before a change gives a retrievable copy for the change record. Keeping that record, approving the change and reconciling the output remain the bank's own process. For the wider security picture, see enterprise reporting security and, for deployment questions, on-prem vs cloud reporting deployment.
Getting Started
| Review area | CxReports mechanism | What stays with the bank |
|---|---|---|
| Who can use the assistant | AI permission on roles; integration configured per workspace |
Deciding which roles get it |
| Which provider and model | AI Integration (engine, model, own API key) | Provider due diligence and contract |
| What the assistant receives | Report overview, runtime data on request, attached files | Using synthetic or anonymised data in design sessions |
| Reviewing what it changed | Action rows in the chat; Job hold-for-review for generated output | Template approval and the binding check |
| Retrievable previous versions | Data Export of reports, templates and themes | The change record and approvals |
| Retention, logs, generation | Not stated in the documentation | Written confirmation from the vendor |
Documentation:
For the audit-record side of the same review, see compliance-ready reporting. To walk your risk team through the assistant and put the open questions to the CxReports team, request a demo.
This article covers technology review practices. It is not legal or regulatory advice; the supervisory expectations that apply to your institution depend on its charter, size and jurisdiction, and are determined by your compliance and risk functions. The regulatory references reflect the sources cited at the time of writing.