1. Defina o que a máquina tem permissão para fazer
A adequação assistida por AI deve começar com um caso de uso preciso. Um gerente de relacionamento pode usar a tecnologia para recuperar os objetivos declarados pelo cliente, consolidar posições, extrair termos do produto, comparar restrições documentadas, evidenciar inconsistências ou redigir uma explicação em linguagem simples. Cada tarefa tem um risco diferente. A recuperação pode retornar o documento errado. A extração pode omitir uma condição. A comparação pode aplicar a regra errada. A geração pode criar uma afirmação plausível sem fonte.
A empresa deve declarar se o sistema informa, recomenda, decide ou comunica. Deve identificar o usuário, o público de clientes, os produtos, os dados, o modelo, as interfaces, a saída e os usos proibidos. Uma ferramenta aprovada para resumir pesquisas internas não deve ser automaticamente usada para recomendar um produto estruturado complexo. Não se deve presumir que um modelo validado para documentos em inglês tenha desempenho equivalente em outro idioma.
A adequação continua sendo um processo profissional de ponta a ponta. O gerente de relacionamento deve compreender as circunstâncias e os objetivos do cliente, o produto e seus riscos, o motivo da correspondência proposta e a qualidade das evidências de suporte. A tecnologia pode ampliar esse trabalho. Não pode transformar fatos incompletos em uma recomendação confiável.
O limite operacional deve ser expresso por meio de ações permitidas, aprovações exigidas e condições de parada. Documentos de origem ausentes, informações desatualizadas do cliente, objetivos conflitantes, uma divulgação de riscos indisponível ou um produto fora do catálogo aprovado devem interromper o avanço automatizado. Um controle que apenas exibe um aviso enquanto permite a conclusão pode ser ineficaz quando a equipe enfrenta pressão de tempo.
Estrutura do autor. Cada camada preserva suas evidências, seu responsável e seu status de decisão.
Tabela 1. Registro mínimo de evidências de adequação
| Classe de evidência | Conteúdo exigido | Campo de status | Pergunta do revisor |
|---|---|---|---|
| cliente | objetivos, horizonte, capacidade, conhecimento, experiência, liquidez, restrições e preferências | verificado, declarado pelo cliente, calculado, desatualizado ou ausente | quais fatos sustentam o resultado proposto? |
| carteira | posições, exposições, concentrações, fluxos de caixa, restrições fiscais ou legais, quando relevantes | atual, reconciliado ou exceção | como a recomendação altera a exposição total? |
| produto | termos, riscos, custos, liquidez, cenários, mercado-alvo e conflitos | aprovado, vigente, substituído ou restrito | qual documento autoritativo sustenta cada atributo? |
| política | regra de adequação, regra de governança de produto, autoridade delegada e divulgação exigida | aplicável, condicional ou não resolvido | qual regra permite, restringe ou impede a ação? |
| máquina | modelo, versão, prompt, conjunto de entradas, fontes de recuperação, saída e indicador de confiança | aceito, contestado, substituído ou rejeitado | o que a tecnologia contribuiu e onde ela pode falhar? |
| humano | análise, alternativas consideradas, julgamento, substituição, aprovação e comunicação | rascunho, aprovado, escalado ou recusado | o aprovador conseguiria explicar e defender o resultado? |
A estrutura do registro deve ser adaptada ao arcabouço jurídico e de conduta aplicável.
2. Trate a explicabilidade como reconstrução de evidências
A expressão caixa-preta pode se referir a vários problemas diferentes. Um modelo pode ser matematicamente complexo. Um fornecedor pode proteger sua propriedade intelectual. Um gerente de relacionamento pode receber uma classificação sem citações de fonte. Um revisor de conformidade pode ver a resposta final, mas não ter os insumos e o caminho da decisão. A governança deve identificar a opacidade real e tratar seu efeito.
Para fins de adequação, explicabilidade prática significa que um revisor qualificado consegue reconstruir por que um produto foi considerado, por que alternativas foram excluídas, quais fatos do cliente importaram, quais atributos do produto importaram, o que o sistema produziu, o que o humano alterou e o que foi comunicado. Essa reconstrução não exige divulgação pública dos pesos do modelo. Ela exige evidências relevantes para a decisão.
O registro deve preservar a identidade da fonte, a data de vigência, a versão, o horário de extração e a transformação. Se um assistente AI afirmar que um produto tem liquidez mensal, o arquivo de recomendação deve vincular ao documento aprovado e à disposição que sustenta essa afirmação. Se ele estimar a exposição da carteira, o registro deve preservar posições, preços, método e carimbo de data e hora. Se ele interpretar o objetivo em texto livre de um cliente, o gerente de relacionamento (RM) deve confirmar a interpretação.
As explicações devem corresponder ao público. O cliente precisa de razões, riscos, custos e alternativas claros. O gerente de relacionamento precisa de evidências acionáveis e incerteza. A conformidade precisa de rastreabilidade e aplicação de regras. A equipe de risco de modelo precisa de dados, testes e análise de falhas. A alta administração precisa de tendências de resultados, incidentes e controles.
3. Construa a linhagem de evidências da fonte à comunicação
A linhagem de evidências rastreia informações da origem até a recomendação e a comunicação final. Ela deve identificar registros de clientes, documentos de produtos, cálculos, políticas, chamadas de modelo, trechos recuperados, edições e aprovações. Um identificador estável para cada item permite que a empresa reproduza o registro depois que documentos de origem ou modelos mudarem.
Os controles de linhagem devem abordar a atualidade. As circunstâncias do cliente podem mudar. Termos de produtos, custos, liquidez e classificações de risco podem ser alterados. Visões de investimento e condições de mercado podem mudar. O processo deve definir quão atual cada classe de evidência deve ser e o que ocorre quando uma fonte está fora dessa janela.
A linhagem também deve preservar a ausência e o conflito. Uma necessidade de liquidez ausente deve permanecer visível. Respostas conflitantes do cliente não devem ser resolvidas silenciosamente por um modelo. O gerente de relacionamento (RM) deve buscar esclarecimento, registrar a resolução ou interromper a recomendação. Informação desconhecida é um fato de decisão.
O sistema deve separar o conteúdo da fonte do conteúdo gerado. Trechos recuperados, campos calculados e narrativa redigida podem ser exibidos de forma diferente. Uma afirmação sem fonte atribuível deve ser sinalizada para verificação ou removida antes da comunicação.
Estrutura do autor. O pacote de evidências preserva registros de fonte, transformação, decisão e comunicação.
4. Coloque as obrigações de adequação antes do design do modelo
As abordagens oficiais variam conforme o mercado. A FCA aplica estruturas existentes, incluindo o Consumer Duty e a responsabilização da alta administração, ao uso de AI. A ESMA declarou que as empresas que utilizam AI em serviços de investimento devem continuar a cumprir as obrigações do MiFID II e destacou riscos de viés, tomada de decisão opaca, dependência excessiva, privacidade e segurança. A SFC de Hong Kong identifica recomendações de investimento, consultoria e pesquisa produzidas por modelos de linguagem generativos de AI como usos de alto risco que exigem controles adicionais.
A FINRA lembra às empresas membros que as regras de valores mobiliários neutras em relação à tecnologia continuam a se aplicar à AI generativa. A revisão da ASIC sobre licenciados em serviços financeiros identificou o risco de a governança ficar aquém da adoção, incluindo lacunas relativas à equidade, ao viés e a sistemas de terceiros. O relatório da IOSCO sobre AI e aprendizado de máquina aborda governança, testes, qualidade de dados, terceirização, divulgação e supervisão humana para intermediários de mercado e gestores de ativos.
O Modelo de Estrutura de Governança de AI de Singapura oferece uma referência de design voluntária e intersetorial baseada em explicabilidade, transparência, equidade e tomada de decisão centrada nas pessoas. Os materiais da DFSA e as comunicações atuais de supervisão fornecem evidências sobre governança, responsabilização, supervisão e explicabilidade no âmbito dos serviços financeiros. Cada fonte tem seu próprio status legal e escopo.
Uma empresa deve mapear os requisitos exatos aplicáveis à sua entidade, licença, serviço, cliente e produto. As disciplinas comuns de design podem apoiar um modelo de controle do grupo. A análise jurídica local deve determinar testes de adequação, divulgações, aprovações, registros, reclamações, proteção de dados e notificações às autoridades supervisoras.
Tabela 2. Evidências internacionais de design para adequação assistida por AI
| Mercado | Material oficial | Implicação de design | Limite importante |
|---|---|---|---|
| Reino Unido | Abordagem da FCA em relação a AI e materiais sobre o Consumer Duty | preservar os resultados de necessidades do cliente, valor, compreensão e suporte; manter a responsabilização da alta administração | as regras existentes se aplicam conforme o escopo da empresa, do serviço e do produto |
| União Europeia | Declaração da ESMA sobre AI em serviços de investimento | controlar viés, resultados opacos, dependência excessiva, privacidade e segurança, cumprindo as obrigações do MiFID II | A Lei de AI da UE e as regras setoriais exigem análise separada de aplicabilidade |
| Hong Kong | Circular da SFC sobre modelos de linguagem generativa de AI | classificar consultoria e recomendações como de alto risco; aplicar governança do ciclo de vida e salvaguardas adicionais | a circular aplica-se às sociedades licenciadas no âmbito indicado |
| Austrália | Relatório 798 da ASIC | alinhar a governança à escala e à complexidade de AI; abordar equidade, viés e risco de terceiros | as conclusões refletem os licenciados analisados e as obrigações existentes |
| Estados Unidos | Aviso Regulatório 24-09 da FINRA | o uso de tecnologia não substitui os deveres de supervisão, comunicação, registros e conduta | o aviso dirige-se às empresas membros da FINRA e não cria novos requisitos |
| Singapura | Estrutura Modelo de Governança de AI da PDPC | definir funções, envolvimento humano, controles operacionais e comunicação com as partes interessadas | voluntária e intersetorial; os requisitos setoriais permanecem separados |
| DIFC | Pesquisa da DFSA sobre AI e materiais de supervisão | estabelecer responsabilização clara, supervisão, uso ético de dados e gestão de riscos | as obrigações exatas dependem do DFSA Rulebook e da atividade autorizada |
| Internacional | IOSCO AI e relatório final de aprendizado de máquina | regem o desenvolvimento, os testes, o monitoramento, os dados, os provedores, a divulgação e a intervenção humana | as recomendações operam por meio das jurisdições dos membros |
Os materiais têm efeitos jurídicos diferentes; as empresas devem confirmar a aplicabilidade atual e as obrigações locais.
5. Atribuir direitos de decisão a pessoas reais
A supervisão humana deve ser mais do que um clique. O aprovador precisa de conhecimento, tempo, evidências e autoridade adequados para contestar o resultado. O modelo operacional deve identificar quais decisões pertencem ao RM, ao responsável pelo produto, ao compliance, ao comitê de investimentos, ao responsável pelo modelo, à área de tecnologia e à alta administração.
O RM deve ser responsável pela exatidão das informações do cliente capturadas, pela relevância dos objetivos declarados, pela explicação das alternativas e pela justificativa profissional da recomendação. O responsável pelo produto deve ser responsável pelas evidências do produto aprovado, pelo mercado-alvo, pelas restrições e pelos eventos do ciclo de vida. O compliance deve ser responsável pela interpretação das regras, pela vigilância e pelo desenho da escalada. A área de risco de modelo ou uma função de controle adequadamente independente deve ser responsável pelos padrões de validação e pelas limitações materiais.
A segregação é importante. A mesma equipe comercial não deve aprovar o caso de uso, selecionar evidências de validação, avaliar o desempenho e sanar suas próprias deficiências sem contestação independente. Empresas menores podem aplicar proporcionalidade por meio de comitês ou especialistas externos, preservando decisões com responsabilização clara.
A autoridade delegada deve ser explícita. Uma alocação de baixo risco e não complexa dentro de um mandato documentado pode seguir um fluxo de trabalho padrão. Um produto concentrado, ilíquido, alavancado ou novo pode exigir aprovação adicional do produto e de compliance. Uma limitação material do sistema pode exigir a suspensão temporária da função AI.
Tabela 3. Matriz de direitos de decisão
| Decisão | Propõe | Contesta | Aprova | Evidências exigidas |
|---|---|---|---|---|
| aprovar um caso de uso de adequação AI | responsável pelo negócio e pelo modelo | compliance, risco, segurança da informação e proteção de dados | executivo responsável ou comitê | escopo do caso de uso, avaliação de riscos, validação e controles operacionais |
| adicionar um produto à prateleira habilitada pelo AI | responsável pelo produto | investimentos, compliance e operações | comitê de produtos | termos atuais, mercado-alvo, riscos, custos, liquidez e mapeamento de dados |
| fazer uma recomendação ao cliente | gerente de relacionamento | controles de fluxo de trabalho e segunda linha quando acionada | gerente de relacionamento autorizado ou aprovador delegado | registro completo de evidências, alternativas e justificativa |
| anular um alerta do sistema | gerente de relacionamento | compliance ou revisor designado | autoridade definida pela gravidade | alerta, motivo, evidências, impacto no cliente e aprovação |
| alterar modelo, prompt ou fonte de recuperação | responsável pelo modelo ou pela tecnologia | validação, compliance e segurança | autoridade para alterações | avaliação de impacto, testes de regressão, versão e rollback |
| suspender o sistema | líder do incidente, compliance ou responsável pelo modelo | responsável de negócio quando o tempo permitir | autoridade de incidente designada | limiar de violação, casos afetados, plano de contenção e comunicação |
Os títulos são ilustrativos; as empresas devem alocar pessoas responsáveis nominalmente no âmbito de sua estrutura de governança.
6. Criar pontos de controle humano significativos
Pontos de controle devem ocorrer antes que uma recomendação se torne voltada ao cliente ou executável. Um primeiro ponto de controle pode testar se as evidências do cliente estão completas e atualizadas. Um segundo pode confirmar que o produto está aprovado e que as evidências estão atualizadas. Um terceiro pode testar adequação à carteira, concentração, liquidez e custos. Um quarto pode exigir que um gerente de relacionamento (RM) compare alternativas e registre o julgamento. Um ponto de controle final pode confirmar divulgação, aprovação e retenção de registros.
A automação deve parar quando uma condição material falhar. Exemplos incluem objetivos do cliente inconsistentes, informações ausentes sobre capacidade de perda, documento de produto expirado, dados de custo indisponíveis, produto não aprovado, violação de concentração, resultado não respaldado ou incidente de sistema. A mensagem de parada deve explicar qual evidência está faltando e quem pode resolvê-la.
Uma exceção deve ser rara, específica e revisável. Ela deve identificar o alerta, o tomador de decisão, a autoridade, as evidências de apoio, o impacto no cliente e a expiração. Exceções repetidas podem indicar que uma regra está mal calibrada, que a equipe está contornando salvaguardas ou que o processo do produto é fraco.
A amostragem após aprovação continua útil, particularmente para casos de menor risco que não recebem pré-aprovação. As amostras devem ser baseadas em risco e incluir novos produtos, clientes vulneráveis, mudanças materiais, altas concentrações, produtos complexos, casos transfronteiriços e gerentes de relacionamento (RMs) com padrões incomuns.
Estrutura do autor. Uma falha material encaminha o caso para esclarecimento, escalonamento ou rejeição.
7. Validar o sistema completo de recomendação
A validação deve testar o processo completo, e não apenas o modelo. O sistema inclui fontes de dados, recuperação de documentos, regras, cálculos, prompts, modelo, interface, decisões humanas e registros subsequentes. Um modelo tecnicamente preciso ainda pode produzir resultados inadequados se os dados do cliente estiverem desatualizados ou se o fluxo de trabalho omitir a exposição total da carteira.
O plano de validação deve abranger uso pretendido, uso proibido, qualidade dos dados, precisão de recuperação, precisão de extração, reprodutibilidade dos cálculos, estabilidade do modelo, alucinação, viés, injeção de prompt, acesso, completude dos registros, fatores humanos e alternativa de contingência. Os testes devem incluir casos comuns, casos-limite e entradas adversariais deliberadas.
Medidas de desempenho precisam ter significado para a decisão. A precisão de recuperação pode mostrar se o sistema encontrou documentos aprovados. A precisão de citação pode mostrar se as afirmações são respaldadas por passagens citadas. As taxas de falsos negativos podem medir restrições não detectadas. As taxas de exceção podem revelar atrito no fluxo de trabalho ou controles fracos. Os testes de resultados podem examinar se clientes em situações semelhantes recebem tratamento materialmente inconsistente.
Os limiares de aceitação são decisões da administração informadas por obrigações, danos e apetite ao risco. Um limiar adequado para redigir um resumo de reunião pode ser inadequado para uma recomendação ao cliente. As limitações devem ser registradas e traduzidas em restrições de uso, verificações humanas ou rejeição do caso de uso.
Tabela 4. Plano de validação e monitoramento
| Domínio de teste | Teste pré-uso | Evidências de produção | Consequência da decisão |
|---|---|---|---|
| dados do cliente | completude, atualidade, reconciliação e casos de conflito | taxa de campos ausentes, registros desatualizados e correções manuais | interromper o caso afetado ou restringir a população elegível |
| Evidências do produto | recuperação em fontes aprovadas, extração de versão e de atributos | precisão das citações, documentos expirados e exceções de produto | remover o produto ou atualizar as evidências |
| regras de política | casos positivos, negativos e de limite | gatilhos de regras, falsos negativos e padrões de substituição | corrigir a regra, revisar novamente os casos ou suspender o fluxo de trabalho |
| saída generativa | suporte factual, consistência, incerteza e alegações proibidas | taxa de declarações sem suporte, edições e reclamações | fortalecer a recuperação, o prompt ou a revisão humana |
| justiça e resultados | casos comparáveis, proxies e cenários de clientes vulneráveis | diferenças de resultados, recusas, escalonamentos e remediação | investigar a causa e alterar dados, processo ou acesso |
| segurança e resiliência | acesso, injeção de prompt, vazamento de dados, falha do provedor e fallback | alertas, incidentes, indisponibilidade e testes de recuperação | conter, revogar acesso, usar fallback ou suspender |
Os limites devem ser aprovados para o caso de uso específico; esta tabela define tipos de teste, não benchmarks numéricos.
8. Governar dados de clientes como evidência de recomendação
Os dados de clientes raramente são um único registro limpo. Os objetivos podem ser expressos em reuniões, questionários, e-mails e instruções de portfólio. A tolerância a risco pode ser capturada por meio de uma pontuação, enquanto a capacidade de suportar perdas depende de compromissos financeiros e liquidez. Conhecimento e experiência podem variar entre produtos. Pessoas jurídicas, trusts e estruturas familiares podem envolver vários tomadores de decisão.
O sistema deve reter a origem e o status de cada fato relevante. Uma preferência declarada pelo cliente é diferente de um saldo de conta verificado. Uma exposição calculada é diferente de um julgamento do RM. Uma resposta ausente é diferente de uma resposta negativa. Essas distinções devem sobreviver à ingestão no modelo.
A interpretação de texto livre exige confirmação. Se um cliente disser que o capital deve permanecer disponível para a compra de um imóvel, um sistema AI pode classificar uma necessidade de liquidez. O RM deve confirmar prazo, valor, moeda e certeza. O fato registrado deve refletir o que o cliente confirmou.
A minimização de dados e os controles de acesso continuam importantes. Um modelo deve receber apenas as informações necessárias para a tarefa aprovada. Informações pessoais sensíveis não devem ser transferidas para uma ferramenta pública não aprovada. Retenção, exclusão, transferência transfronteiriça e direitos dos clientes devem ser avaliados sob o arcabouço de dados aplicável.
9. Governar as evidências do produto ao longo do seu ciclo de vida
Uma prateleira de produtos muda continuamente. Os termos podem ser alterados, as subscrições suspensas, as restrições de liquidez aplicadas, os gestores substituídos e as classificações de risco atualizadas. Os sistemas de adequação devem consumir evidências aprovadas do produto com responsabilidade clara e datas de vigência.
O registro do produto deve abranger objetivo, estratégia, instrumentos, alavancagem, liquidez, avaliação, taxas, cenários de desempenho, características de perda, moeda, mercado-alvo, conflitos, restrições de distribuição e documentos relevantes. Cada atributo relevante deve estar vinculado a uma fonte autoritativa. Textos de marketing não devem substituir documentos jurídicos e documentos aprovados do produto.
Eventos do produto devem acionar ações de fluxo de trabalho. Um resgate suspenso deve alterar as evidências de liquidez. Uma mudança de gestor ou de estratégia pode exigir uma reavaliação. Uma atualização de documento deve invalidar trechos substituídos. O sistema deve identificar recomendações ou posições de clientes afetadas por mudanças materiais.
Produtos complexos merecem controles mais profundos. Comparações geradas por modelos podem ocultar dependência de trajetória, crédito do emissor, alavancagem, rescisão antecipada e limitações de cenário. O RM deve compreender o retorno potencial e explicar resultados adversos plausíveis. Uma pontuação padrão não deve substituir essa análise.
10. Comparar a recomendação com alternativas credíveis
A adequação é reforçada quando o RM compara alternativas realistas. O conjunto deve incluir a manutenção da carteira atual quando apropriado, opções de menor custo ou mais líquidas, diferentes vias de implementação e o produto proposto. A comparação deve usar os objetivos do cliente e a carteira total.
AI pode ajudar a identificar produtos que atendam a filtros documentados. Também pode restringir o conjunto de forma excessivamente agressiva por meio de premissas incorporadas ou prioridades comerciais. A cobertura da prateleira, a lógica de classificação, os conflitos e os produtos excluídos devem, portanto, estar visíveis para o RM e o revisor.
Os custos devem ser considerados de forma cumulativa e em contexto. Taxas do produto, encargos de assessoria, custos de transação, custos de financiamento, efeitos cambiais e custos de saída podem alterar o resultado. A explicação da recomendação deve descrever o valor esperado da opção selecionada e as desvantagens materiais em relação às alternativas.
Quando a empresa recebe taxas de colocação, retrocessões ou outros benefícios, o conflito deve ser tratado no âmbito do arcabouço aplicável. O modelo não deve otimizar a receita comercial enquanto apresenta o resultado como orientado pelo cliente. A lógica de classificação e as substituições manuais devem ser monitoradas quanto a esse risco.
Tabela 5. Comparação hipotética cliente-produto
| Fator de decisão | Carteira diversificada atual | Fundo balanceado com liquidez diária | Alocação em mercados privados | Evidência e pergunta do RM |
|---|---|---|---|---|
| objetivo declarado | crescimento moderado de longo prazo | amplamente alinhado | potencialmente alinhado ao objetivo de retorno | qual objetivo tem prioridade e em que horizonte? |
| liquidez | diariamente | diariamente | lock-up de vários anos com transferência limitada | que necessidade de caixa poderia surgir antes da saída? |
| capacidade de perda | capacidade moderada hipotética | dentro do intervalo assumido | a exposição a drawdown e a chamadas de capital pode ultrapassar o nível de conforto | a capacidade de suportar perdas foi verificada e abrange todo o portfólio? |
| concentração | linha de base atual | alteração modesta | aumenta a concentração em ativos ilíquidos e em gestores | qual limite se aplica após a transação? |
| custo | custo divulgado existente | médio hipotético | alto hipotético com elementos relacionados ao desempenho | quais custos são certos, contingentes e comparáveis? |
| ônus operacional | estabelecido | subscrição padrão | chamadas de capital, complexidade fiscal e de relatórios | o cliente e a empresa conseguem dar suporte ao ciclo de vida? |
| resultado ilustrativo | manter | candidato à análise | exige revisão aprimorada | que evidências mudariam a decisão? |
Todo valor e avaliação é uma premissa hipotética da administração usada para demonstrar a documentação; nenhum produto é recomendado.
11. Dê ao gerente de relacionamento (RM) um cartão de explicação
A interface deve ajudar um gerente de relacionamento (RM) a raciocinar, e não apenas a aprovar. Um cartão de decisão pode mostrar o objetivo do cliente, fatos críticos, ação proposta, alternativas, fontes de apoio, riscos relevantes, custos, incerteza, conflitos e aprovações necessárias. Ele deve expor evidências ausentes e desatualizadas.
O cartão deve distinguir conteúdo produzido por máquina. Trechos recuperados podem ser exibidos com links para as fontes. Os cálculos podem mostrar o método e as entradas. A narrativa gerada pode ser editável e visivelmente marcada dentro do fluxo de trabalho interno. A comunicação final com o cliente deve conter apenas conteúdo verificado e aprovado.
Uma explicação deve ser específica o suficiente para ser testada. Afirmações como 'adequado para diversificação' são frágeis sem identificar a concentração atual, a mudança proposta, o horizonte temporal, a liquidez e o risco. Um revisor deve ser capaz de entender como a recomendação atende ao objetivo do cliente e onde ela pode falhar.
A interface deve limitar o viés de automação. O produto proposto não deve ser visualmente dominante antes que o RM revise as evidências. Alternativas e condições de parada devem receber destaque comparável. Os indicadores de confiança devem ser definidos e testados; um tom refinado nunca deve ser tratado como confiança.
Estrutura do autor. O cartão interno destaca evidências, incerteza, alternativas e responsabilidade pela decisão.
12. Controle de prompts, recuperação e mudanças no modelo
Um sistema generativo pode mudar mesmo quando a interface do usuário parece estável. O provedor do modelo pode atualizar o serviço subjacente. A empresa pode alterar um prompt de sistema, índice de recuperação, analisador de documentos, temperatura, configuração de segurança ou regra de pós-processamento. Cada mudança relevante pode alterar o processo de recomendação.
O inventário de mudanças deve registrar componente, responsável, versão, data, justificativa, testes, aprovação e reversão. Os testes de regressão devem incluir casos conhecidos, comuns, de limite e de falha. Uma mudança no analisador de documentos de produto deve ser testada com tabelas, notas de rodapé, páginas digitalizadas e documentos alterados.
Os prompts são artefatos de controle. Prompts de sistema, modelos aprovados e instruções proibidas devem ter versionamento e controle de acesso. Prompts do usuário e saídas do modelo devem ser retidos quando exigido e seguro. Injeção de prompt e conteúdo malicioso em documentos devem ser incluídos nos testes de segurança.
Atualizações de modelos de terceiros exigem monitoramento contratual e técnico. A empresa deve compreender os arranjos de notificação, registros de serviço, uso de dados, retenção, subprocessadores, região, segurança, resiliência e saída. Quando um provedor não divulgar detalhes do modelo, a empresa ainda pode testar o desempenho observável, restringir entradas e saídas, exigir evidências e preservar a capacidade de contingência.
13. Projete substituições manuais como sinais de risco
Uma substituição manual pode ser apropriada quando uma regra tem uma limitação documentada e uma pessoa qualificada tem melhores evidências. Também pode ser uma forma de contornar um controle necessário. A governança deve distinguir esses casos.
O registro de exceções deve incluir a condição disparadora, a saída do sistema, a justificativa humana, as evidências, a autoridade, o efeito no cliente e a validade. Exceções materiais devem passar por revisão independente antes da ação. Exceções de menor risco podem ser amostradas após a ação, conforme a política.
Os padrões importam mais do que totais isolados. Uma taxa alta para um produto pode indicar dados ruins do produto. Uma taxa alta para um RM pode indicar preocupações de treinamento ou conduta. Exceções repetidas a uma regra de liquidez podem evidenciar pressão comercial. Exceções que melhoram os resultados dos clientes podem evidenciar uma limitação do modelo que deve ser corrigida.
O relatório de gestão deve conectar exceções a decisões. O responsável deve decidir se altera a regra, melhora os dados, treina novamente a equipe, restringe o produto, revisa novamente os casos de clientes ou suspende o sistema. Fechar o chamado sem testar a mudança deixa o risco sem resolução.
14. Monitorar resultados, deriva e conduta
O monitoramento em produção deve abranger o desempenho do sistema e os resultados dos clientes. Medidas técnicas incluem disponibilidade, latência, recuperação, precisão das citações, erros do modelo e eventos de segurança. Medidas de processo incluem conclusão, paradas, escalonamentos, exceções, tempo de revisão e qualidade dos registros. Medidas de resultado incluem concentração, custo, reclamações, cancelamentos, remediação e diferenças entre grupos de clientes.
A deriva pode surgir de condições de mercado, mudanças de produto, comportamento do cliente, fontes de dados e atualizações do modelo. Uma pontuação de precisão estável pode ocultar uma composição de casos em mudança. O monitoramento deve, portanto, segmentar por complexidade do produto, tipo de cliente, geografia, canal, RM e versão do modelo quando legal e operacionalmente apropriado.
A vigilância de conduta pode examinar se as recomendações se concentram em produtos com maior benefício comercial, se os alertas de risco são desconsiderados, se clientes vulneráveis recebem resultados diferentes e se as explicações geradas omitem desvantagens. Qualquer análise de atributos protegidos ou sensíveis exige governança jurídica e de privacidade adequada.
Os limites devem disparar ações definidas. Uma alegação crítica sem suporte pode exigir contenção imediata. Uma taxa crescente de exceções pode exigir amostragem reforçada. Uma falha no documento do produto pode exigir a remoção do produto da prateleira habilitada. Um impacto material no cliente pode exigir identificação de casos, comunicação e remediação.
Estrutura do autor. Os valores são premissas gerenciais hipotéticas criadas para demonstrar um design de painel.
15. Preparar para incidentes e remediação de clientes
Um incidente AI pode envolver aconselhamento sem suporte, dados incorretos de produto, tratamento tendencioso, vazamento de dados, acesso não autorizado, falha de fornecedor ou registros ausentes. O plano de resposta deve conectar a contenção tecnológica às decisões de clientes e regulatórias.
O líder do incidente deve identificar versões afetadas do modelo, datas, usuários, clientes, produtos e saídas. A linhagem preservada torna isso possível. A empresa deve parar ou restringir o caso de uso, proteger as evidências, aplicar procedimentos alternativos e decidir se recomendações passadas exigem revisão.
A gravidade deve refletir o dano real e potencial ao cliente, a violação regulatória, a sensibilidade dos dados, o volume e a duração. As obrigações de notificação dependem da jurisdição e dos fatos. Equipes jurídicas, de compliance, de proteção de dados, de segurança da informação, de negócios e de comunicação precisam de autoridade definida e rotas de escalonamento.
A remediação deve abordar casos individuais e a causa sistêmica. Clientes afetados podem exigir correção, explicação, ação de portfólio, ajuste de taxas ou compensação, conforme as obrigações e circunstâncias aplicáveis. A resposta subjacente pode exigir correção de dados, alteração de modelo, redesenho de regras, revisão mais rigorosa, ação junto ao fornecedor ou retirada do caso de uso.
16. Gerencie AI de terceiros como parte do processo regulamentado
A diligência devida do fornecedor deve examinar o serviço, o modelo, os dados, a segurança, a resiliência, o processo de mudança, as evidências de auditoria, os subprocessadores e os direitos contratuais. A profundidade deve refletir se o fornecedor recupera informações, classifica produtos, cria conteúdo de aconselhamento ou participa de uma decisão do cliente.
A empresa deve entender como os dados dos clientes e da empresa são usados. Deve determinar se prompts ou resultados treinam modelos do fornecedor, onde os dados são processados, por quanto tempo são retidos, quem pode acessá-los e como funciona a exclusão. A linguagem de confidencialidade deve estar alinhada à configuração técnica.
A supervisão operacional deve incluir disponibilidade, desempenho, incidentes, mudanças materiais e recuperação. Um plano de saída deve preservar prompts, registros, evidências de produtos, decisões de clientes e um processo manual ou alternativo viável. A portabilidade é importante porque o registro da recomendação pode sobreviver ao contrato de tecnologia.
A responsabilização deve permanecer clara. Um fornecedor pode fornecer um modelo e ainda assim não ter o contexto do cliente e a responsabilidade regulatória necessários para aprovar uma recomendação. A empresa de gestão de patrimônio deve manter a governança e as evidências necessárias para suas próprias obrigações.
17. Treine os RMs para questionar o sistema
O treinamento deve abordar o caso de uso aprovado, as evidências, as limitações, o uso proibido, a comunicação com o cliente, as intervenções manuais, os incidentes e o fallback. Deve usar exemplos realistas em que o sistema está correto, incompleto e erra com confiança.
Os RMs devem ser capazes de identificar afirmações sem suporte, termos de produtos desatualizados, fatos inconsistentes do cliente, premissas ocultas e efeitos de portfólio. Devem entender que fluência não é evidência. Um modelo que fornece uma explicação clara ainda pode se basear na fonte errada.
A avaliação de competência deve envolver decisões observadas. Um teste curto de conhecimento pode estabelecer a compreensão. O trabalho com cenários pode mostrar se o RM questiona a ferramenta, busca fatos faltantes, compara alternativas e registra a justificativa. Erros repetidos devem levar a coaching direcionado, acesso restrito ou reavaliação.
Os gestores devem monitorar a carga de trabalho. A revisão humana perde valor se as filas de aprovação forem muito grandes, se as evidências forem difíceis de navegar ou se o timing comercial desestimular o questionamento. A capacidade é uma condição de controle.
18. Implemente a estrutura em 180 dias
A implementação deve começar com um inventário dos usos existentes e planejados de AI. O uso paralelo por meio de ferramentas públicas deve ser incluído. Cada caso de uso deve ter um responsável de negócio, classificação de risco, mapa de dados, fornecedor, status de aprovação e restrição operacional.
Um piloto delimitado deve usar uma população definida de clientes e produtos. Deve testar a cadeia de evidências, os pontos de controle, a interface do RM, o registro, o monitoramento e o fallback. Os resultados do piloto devem incluir casos que falharam e o comportamento da equipe, não apenas a produtividade.
A expansão deve seguir a capacidade verificada. A cobertura de produtos pode ser ampliada após a governança das fontes estar estável. A cobertura de clientes pode ser ampliada após casos extremos e riscos de equidade serem testados. Novos idiomas e mercados exigem suas próprias evidências e análise jurídica.
O conselho de administração ou o comitê delegado deve receber uma decisão sobre o estado operacional ao final do programa. O pacote deve descrever usos aprovados, limitações, resultados de validação, incidentes, riscos não resolvidos, salvaguardas para clientes, responsabilização e próxima revisão.
Tabela 6. Roteiro de implementação de 180 dias
| Período | Trabalho principal | Resultado exigido | Ponto de aprovação |
|---|---|---|---|
| dias 1 a 30 | inventário, perímetro legal, propriedade e classificação de casos de uso | AI registro, usos proibidos, responsáveis designados e linha de base de evidências | aprovar escopo e piloto |
| dias 31 a 60 | design de cliente, produto, política e linhagem | mapa de fontes, regras de atualidade, pontos de controle e especificação de registros | aprovar o padrão de evidências |
| dias 61 a 90 | testes de validação, segurança e fatores humanos | resultados de testes, limitações, plano de contingência e remediação | permitir, restringir ou rejeitar o uso piloto |
| dias 91 a 120 | piloto controlado e revisão reforçada de casos | resultado, substituição manual, incidente e evidências do usuário | decidir sobre a expansão de produtos e clientes |
| dias 121 a 150 | controles, monitoramento e treinamento do provedor | contratos, dashboard, registros de competência e plano de resposta | aceitar o risco residual e os limites operacionais |
| dias 151 a 180 | contestação independente e revisão do estado operacional | pacote de asseguração, ações em aberto e ciclo contínuo de testes | aprovar o estado de produção ou aplicar restrição adicional |
O cronograma é um modelo ilustrativo de sequenciamento e deve ser adaptado ao porte da empresa, ao risco e à capacidade existente.
19. Tornar o reporte ao conselho útil para a tomada de decisão
A alta administração precisa de uma visão do uso, da exposição, do desempenho e do risco não resolvido. O relatório deve mostrar casos de uso ativos, clientes e produtos afetados, mudanças materiais, status de validação, limitações, desempenho dos controles, overrides, incidentes, reclamações, remediação e dependências de fornecedores.
As métricas devem estar conectadas a limiares e ações. Uma taxa de suporte a citações tem valor quando a gestão sabe quais falhas afetam as decisões dos clientes e qual resposta se segue. Uma contagem de overrides tem valor quando segmentada por motivo, produto, RM e resultado.
O conselho deve ver o perímetro operacional. O pacote deve identificar quais funções estão habilitadas, quais são proibidas, quais populações são excluídas e qual fallback manual existe. As decisões de expansão devem indicar as evidências exigidas antes da aprovação.
A asseguração deve incluir contestação independente. Monitoramento de conformidade, auditoria interna, validação de modelos, testes de segurança e revisão externa podem, cada um, fornecer evidências diferentes. As constatações devem ter responsáveis claros, prazos e testes de encerramento.
Arcabouço do autor. O reporte vincula a exposição e as evidências de controle a decisões explícitas da administração.
20. Faça do aconselhamento confiável a proposta comercial
Os clientes podem se beneficiar de preparação mais rápida, evidências mais consistentes e comparações mais claras. A confiança depende de como a empresa governa a recomendação. O RM deve ser capaz de explicar quais informações foram usadas, qual foi a contribuição da tecnologia, qual julgamento o RM fez e quais limitações permanecem.
A empresa deve descrever com precisão o uso de AI. Alegações amplas de objetividade ou de automação sem erros são inadequadas. A comunicação com o cliente deve concentrar-se no serviço, nas salvaguardas, nas limitações relevantes e no canal para dúvidas ou correção. Os requisitos de divulgação dependem do arcabouço aplicável e dos fatos.
Um processo de adequação controlado pode sustentar a escala. As evidências de produtos e clientes tornam-se reutilizáveis, as decisões tornam-se revisáveis e as fragilidades recorrentes tornam-se visíveis. Os dados operacionais podem informar a governança de produtos, o treinamento, o desenho do serviço e o suporte ao cliente.
O valor comercial vem de um aconselhamento com responsabilização. Um cliente deve receber uma recomendação fundamentada em evidências atuais, no contexto do portfólio total, em alternativas críveis e no julgamento humano. AI pode ajudar a montar e testar esse registro. As pessoas da empresa continuam responsáveis pela decisão profissional.
Conclusão
A adequação assistida por AI deve ser concebida como um sistema de evidências e decisões. Fatos do cliente, dados de portfólio, evidências de produtos, políticas, transformações realizadas por máquina, julgamento humano e comunicação com o cliente devem permanecer distintos e rastreáveis.
A explicabilidade prática permite que um revisor qualificado reconstrua a recomendação sem exigir acesso aos pesos proprietários do modelo. O registro identifica fontes, versões, cálculos, contribuições do modelo, alternativas, sobrescritas, aprovações e texto final. Evidências ausentes e conflitantes permanecem visíveis.
Materiais oficiais internacionais usam diferentes vias legais. Eles apoiam repetidamente governança, responsabilização, envolvimento humano adequado, qualidade dos dados, testes, monitoramento, supervisão de fornecedores, manutenção de registros e proteção do cliente. Uma empresa de gestão de patrimônio pode traduzir essas disciplinas em um modelo operacional comum, ao mesmo tempo que conclui a análise jurídica específica de cada jurisdição.
A questão determinante é direta: o gerente de relacionamento e a empresa conseguem demonstrar, com base em evidências atuais, por que a recomendação atende às circunstâncias e aos objetivos documentados deste cliente, como a tecnologia contribuiu, quais alternativas foram consideradas, quais riscos e custos foram explicados e qual pessoa qualificada assumiu a responsabilidade? Uma resposta completa transforma AI de uma ferramenta de produtividade opaca em um componente controlado do aconselhamento profissional.
Referências
- UK Financial Conduct Authority, Nossa abordagem em relação a AI, https://www.fca.org.uk/firms/innovation/ai-approach
- UK Financial Conduct Authority, AI nos serviços financeiros: nossa abordagem, 8 de junho de 2026, https://www.fca.org.uk/news/blogs/ai-financial-services-approach
- UK Financial Conduct Authority, Sobre o Dever do Consumidor, https://www.fca.org.uk/firms/consumer-duty/about
- UK Financial Conduct Authority, PS22/9: Um novo Dever do Consumidor, https://www.fca.org.uk/publications/policy-statements/ps22-9-new-consumer-duty
- Financial Conduct Authority do Reino Unido, Revisão Mills sobre AI em serviços financeiros de varejo, 6 de julho de 2026, https://www.fca.org.uk/news/press-releases/fca-publishes-landmark-review-impact-ai-retail-financial-services
- Autoridade Europeia dos Valores Mobiliários e dos Mercados, Declaração Pública sobre o uso de inteligência artificial na prestação de serviços de investimento de varejo, 30 de maio de 2024, https://www.esma.europa.eu/sites/default/files/2024-05/ESMA35-335435667-5924__Public_Statement_on_AI_and_investment_services.pdf
- Comissão de Valores Mobiliários e Futuros de Hong Kong, Circular para sociedades licenciadas sobre o uso de modelos de linguagem de AI generativa, 12 de novembro de 2024, https://apps.sfc.hk/edistributionWeb/api/circular/list-content/circular/intermediaries/supervision/doc?lang=EN&refNo=24EC55
- Comissão de Valores Mobiliários e Futuros de Hong Kong e outros reguladores de Hong Kong, Circular Conjunta sobre a Expansão do Sandbox de Inteligência Artificial Generativa, 5 de março de 2026, https://apps.sfc.hk/edistributionWeb/gateway/EN/circular/intermediaries/supervision/doc?refNo=26EC11
- Comissão Australiana de Valores Mobiliários e Investimentos, Relatório 798: Cuidado com a lacuna, 29 de outubro de 2024, https://asic.gov.au/regulatory-resources/find-a-document/reports/rep-798-beware-the-gap-governance-arrangements-in-the-face-of-ai-innovation/
- Comissão Australiana de Valores Mobiliários e Investimentos, Revise suas estruturas de governança e gestão de riscos de inteligência artificial, abril de 2025, https://asic.gov.au/about-asic/corporate-publications/newsletters/market-integrity-update/miu-issue-166-april-2025/
- Autoridade Reguladora da Indústria Financeira, Aviso Regulatório 24-09: Obrigações regulatórias ao usar AI generativa e grandes modelos de linguagem, 27 de junho de 2024, https://www.finra.org/rules-guidance/notices/24-09
- Autoridade de Serviços Financeiros de Dubai, Pesquisa sobre Inteligência Artificial 2025, https://www.dfsa.ae/news/new-dfsa-ai-survey-generative-ai-adoption-has-nearly-tripled-within-difc-last-12-months-governance-continues-develop
- Autoridade de Serviços Financeiros de Dubai, Risco Cibernético e de Inteligência Artificial em Serviços Financeiros, 30 de junho de 2025, https://www.dfsa.ae/news/new-dfsa-report-explores-regulatory-insights-cybersecurity-artificial-intelligence-and-quantum-risks
- Comissão de Proteção de Dados Pessoais de Singapura, Estrutura Modelo de Governança de Inteligência Artificial, segunda edição, https://www.pdpc.gov.sg/-/media/files/pdpc/pdf-files/resource-for-organisation/ai/sgmodelaigovframework2.pdf
- Comissão de Proteção de Dados Pessoais de Singapura, abordagem de Singapura para a governança de AI, https://www.pdpc.gov.sg/Help-and-Resources/2020/01/Model-AI-Governance-Framework
- Organização Internacional das Comissões de Valores Mobiliários, O uso de inteligência artificial e aprendizado de máquina por intermediários de mercado e gestores de ativos, setembro de 2021, https://www.iosco.org/library/pubdocs/pdf/IOSCOPD684.pdf
Sobre o Autor
Chennakeshav Adya é pesquisador independente e Sócio-Gerente da Matchpoint Partners. Seu trabalho examina estratégia, formação de capital, avaliação, transações e execução operacional nos mercados privados e públicos.
