O Modelo Operacional de AI: Titularidade, Dados, Controles e Acompanhamento de Benefícios

1. Governar um sistema empresarial em vez de uma coleção de ferramentas de AI

A primeira pergunta do conselho sobre AI deve dizer respeito ao resultado operacional que a empresa pretende mudar. Uma licença, um modelo, um assistente ou um piloto é um insumo. O valor surge quando a empresa muda uma decisão, processo, produto ou proposta de valor ao cliente e consegue sustentar essa mudança dentro dos limites de risco aprovados. O modelo operacional conecta a capacidade tecnológica à ação empresarial responsável.

Essa distinção importa porque um portfólio pode parecer ativo enquanto permanece economicamente fraco. As equipes podem contar demonstrações, usuários, prompts ou documentos gerados. Essas métricas dizem pouco sobre receita, custo, caixa, serviço, qualidade ou risco. Um caso de uso pode ter bom desempenho em um teste controlado e falhar em produção porque o acesso a dados, a integração de fluxos de trabalho, a adoção pelos funcionários, a confiabilidade do fornecedor ou a aceitação pelo cliente é inadequada.

Os Princípios AI da OCDE exigem responsabilização, rastreabilidade e gestão sistemática de riscos em todo o ciclo de vida de AI [1]. O NIST organiza a gestão de riscos de AI em torno de Governar, Mapear, Medir e Gerenciar [3][4]. A ISO/IEC 42001 enquadra a gestão de AI como um sistema de políticas, objetivos e processos continuamente aprimorados [7]. Essas fontes sustentam uma conclusão corporativa prática: a governança de AI pertence ao modelo operacional, e não ao lado dele como um anexo de conformidade.

Uma cadeia operacional completa contém cinco objetos interligados. A estratégia identifica a decisão ou o fluxo de trabalho que vale a pena mudar. Um termo de abertura do caso de uso define escopo, responsável e resultado pretendido. Controles de dados e de modelos estabelecem se a capacidade pode operar de forma responsável. Gates de ciclo de vida determinam se ela pode avançar. Um registro de benefícios mostra se a mudança chegou à demonstração de resultados, ao fluxo de caixa, ao balanço patrimonial, ao resultado de serviço ou à posição de risco. O conselho recebe uma visão integrada dos cinco.

Cada camada tem um responsável designado, um conjunto de evidências, um direito de decisão e uma frequência de revisão.

2. Estabeleça o inventário corporativo antes de priorizar o portfólio

A gestão não pode governar o que não identificou. O inventário deve abranger modelos desenvolvidos internamente, modelos hospedados externamente, AI incorporada em software corporativo, assistentes para funcionários, componentes automatizados de decisão, modelos analíticos, agentes, produtos habilitados por modelos e experimentos relevantes. Também deve registrar o uso sombra descoberto por meio de pesquisas, logs de acesso, dados de compras, controles de rede e revisão de negócios.

A unidade de registro deve ser o caso de uso, e não o nome do fornecedor. Um modelo de uso geral pode atender atendimento ao cliente, programação, marketing e revisão de contratos, com dados, usuários, decisões e consequências diferentes. Por outro lado, um caso de uso pode depender de vários modelos, serviços de recuperação, fontes de dados e aplicações de fluxo de trabalho. O inventário deve representar ambas as relações.

Cada registro precisa de um responsável de negócio, um responsável técnico, uma classificação de risco, usuários pretendidos, partes interessadas afetadas, papel na decisão, categorias de dados, dependências de modelos e fornecedores, jurisdição, status do ciclo de vida, data de aprovação, requisitos de monitoramento, responsável pelos benefícios e rota de desativação. O registro deve identificar se o sistema recomenda, redige, prevê, classifica, decide, age ou controla outro sistema. A autonomia e a reversibilidade muitas vezes importam mais do que a sofisticação do modelo.

O inventário também sustenta a economia do portfólio. Licenças duplicadas, pilotos sobrepostos e pipelines de dados incompatíveis podem ser identificados. Uma capacidade comum pode atender a vários casos de uso, enquanto um modelo especializado de alto custo pode ter um único responsável com escopo restrito. A gestão pode então alocar custos compartilhados, negociar com fornecedores e decidir quais plataformas merecem escala.

Tabela 1. Inventário corporativo mínimo de AI

O inventário reúne evidências operacionais, técnicas, de risco e financeiras em um único registro controlado.

3. Projete o modelo operacional em torno de seis responsabilidades

Um programa AI precisa de mais do que um comitê diretor. Seis responsabilidades devem ser visíveis. O conselho aprova o apetite, o investimento material e a supervisão. O patrocinador executivo é responsável pela tese do portfólio. O proprietário do negócio é responsável pela adoção do fluxo de trabalho e pelo resultado operacional. O proprietário técnico é responsável pela arquitetura, implementação e desempenho do serviço. Funções de controle independentes contestam evidências de risco, privacidade, segurança, jurídicas e de conformidade. A área financeira controla a linha de base dos benefícios e valida o valor realizado.

Em uma organização menor, as funções podem ser combinadas, mas as responsabilidades devem permanecer distintas. A pessoa que propõe um caso de uso pode preparar as evidências. Uma implantação relevante ainda se beneficia da contestação por alguém que não construiu o modelo nem é responsável pelo benefício previsto. A independência pode ser proporcional ao risco, ao custo e à escala organizacional.

Os direitos de decisão devem estar vinculados aos eventos do ciclo de vida. Um responsável pelo produto pode aprovar uma alteração de configuração de baixo impacto. Um comitê de risco pode aprovar uma implantação de alto impacto. O conselho pode reservar para si decisões que envolvam capital relevante, consequências para a força de trabalho, elegibilidade de clientes, segurança, resultados regulados ou exposição reputacional. A autoridade para suspensão emergencial deve ser explícita e estar imediatamente disponível.

Os comitês devem decidir, e não apenas receber apresentações. Cada item da pauta deve indicar a decisão solicitada, as opções, as evidências, o responsável, as limitações não resolvidas e a próxima revisão. O escritório de portfólio mantém padrões e registros. Ele não deve absorver a responsabilidade do executivo cuja função utiliza o sistema.

Tabela 2. Direitos de decisão no modelo operacional AI

R significa responsável pela execução, A significa responsável final, C significa consultado e I significa informado; a alocação exata deve refletir o porte da organização e os requisitos aplicáveis.

4. Converter a estratégia em uma carta de caso de uso controlado

A carta é o menor contrato útil entre estratégia, entrega, controle e finanças. Ela define o problema de negócio, o fluxo de trabalho atual, os usuários pretendidos, as partes afetadas, o papel na decisão, a intervenção proposta, o resultado esperado, as restrições, as dependências, o responsável, o envelope de custos, o plano de evidências e as condições de saída. Deve ser curta o suficiente para governar e precisa o suficiente para ser testada.

O fluxo de trabalho atual merece a mesma atenção que o modelo proposto. A gestão precisa da linha de base do tempo de ciclo, da taxa de erro, da taxa de conversão, do custo, da carga de controle e do resultado para o cliente antes da automação. Processos fracos podem se tornar processos fracos mais rápidos. Um caso de uso deve, portanto, identificar qual etapa muda, quais decisões permanecem humanas e qual processo posterior absorve o resultado.

A carta deve declarar a finalidade pretendida do modelo e os usos proibidos. Um sistema projetado para resumir documentos não deve desviar-se para decisões de elegibilidade de clientes sem uma nova avaliação. Um assistente de vendas não deve incorporar materiais confidenciais de transações porque sua interface torna isso conveniente. Limites claros apoiam o design de acesso, o monitoramento e o treinamento de funcionários.

Os critérios de sucesso devem abranger quatro dimensões: desempenho técnico, adoção operacional, eficácia dos controles e resultado financeiro ou de serviço. Um caso de uso avança somente quando há evidências nas dimensões relevantes para seu nível. Isso evita que pontuações impressionantes do modelo levem um caso operacional fraco pela etapa de aprovação.

A carta também deve definir uma hipótese de decisão. Ela declara quem tomará uma decisão diferente, quais evidências o sistema fornece, com que rapidez a decisão deve ocorrer e como a gestão saberá que a mudança melhorou o resultado. Isso força o patrocinador a identificar a ação humana ou automatizada entre a saída do modelo e o valor. Uma previsão que se limita à qualidade da saída permanece incompleta.

Os critérios de saída são igualmente importantes. A gestão pode interromper um caso de uso quando o problema desapareceu, a intervenção não consegue atingir seu limiar, as condições econômicas do fornecedor mudaram, a carga de controle supera o valor ou uma melhoria de processo mais simples apresenta melhor desempenho. A carta deve identificar como acesso, dados, registros, contratos e dependências a jusante serão encerrados. Uma rota de saída planejada fortalece a disciplina de capital no início do investimento.

5. Classifique os casos de uso em níveis por consequência, autonomia, exposição e reversibilidade

A classificação de risco em níveis deve determinar a intensidade da governança. A classificação pode considerar a consequência do erro, o grau de automação, as partes interessadas afetadas, a escala de exposição, a sensibilidade dos dados, o contexto legal, a novidade do modelo, a explicabilidade, a dependência externa e a reversibilidade. Um assistente de redação utilizado por funcionários treinados difere materialmente de um sistema autônomo que altera o acesso de clientes ou movimenta dinheiro.

O nível deve ser atribuído ao caso de uso em seu contexto. O mesmo modelo pode ter baixo impacto para brainstorming interno e alto impacto quando sua saída influencia recrutamento, crédito, precificação, segurança ou saúde. Essa visão por caso de uso está alinhada às abordagens baseadas em risco encontradas na Lei de AI da UE [9][10], no RMF de AI do NIST [3], na revisão da ASIC sobre a governança de licenciados [27] e na estrutura de risco de modelo da OSFI [29].

Uma estrutura prática pode conter quatro níveis internos. O nível um abrange assistência limitada, com baixa consequência e revisão humana clara. O nível dois abrange recomendações operacionais ou conteúdo que pode afetar clientes ou resultados financeiros. O nível três abrange decisões materiais, dados sensíveis, alta autonomia ou fluxos de trabalho regulamentados. O nível quatro abrange atividades proibidas ou fora do apetite de risco. Níveis internos nunca devem ser apresentados como classificações legais sem análise específica da jurisdição.

A classificação em níveis é dinâmica. O crescimento do volume, novos dados, uma atualização de fornecedor, maior autonomia, novos grupos de usuários ou um incidente relevante podem alterar a classificação. O inventário deve, portanto, registrar o fundamento, o aprovador e a próxima data de revisão.

A matriz é uma ferramenta de gestão; classificações jurídicas exigem análise separada.

Tabela 3. Gatilhos ilustrativos de nível e controles mínimos

A gestão deve adaptar o gatilho e o conjunto de controles à legislação aplicável, ao setor e ao apetite ao risco.

6. Tratar os direitos e a linhagem dos dados como pré-requisitos operacionais

O desempenho e a responsabilização do AI dependem de dados que a organização consiga identificar, usar, proteger e reproduzir. O arquivo de controle de dados deve registrar origem, proprietário, finalidade permitida, base legal ou contratual, classificação, geografia, retenção, testes de qualidade, transformações, linhagem e usos a jusante. Também deve identificar dados pessoais, confidenciais, privilegiados, protegidos por direitos autorais, licenciados e sensíveis.

Os direitos sobre os dados podem ser tão importantes quanto a qualidade dos dados. Um conjunto de dados tecnicamente útil pode não estar disponível para treinamento de modelos, recuperação ou processamento por fornecedores. Contratos com clientes, condições de emprego, direitos de banco de dados, propriedade intelectual, regras de privacidade e obrigações setoriais podem restringir o uso. A aprovação jurídica deve estar vinculada a uma finalidade e a um fluxo de dados específicos, e não ao rótulo amplo de AI.

A linhagem deve acompanhar os dados desde a origem, passando pela preparação, recuperação, contexto do prompt, interação com o modelo, armazenamento de resultados e decisão a jusante. Isso apoia a reprodução, a análise de incidentes, a exclusão, a revisão de acessos e a atribuição de benefícios. A OCDE vincula a responsabilização de AI à rastreabilidade entre conjuntos de dados, processos e decisões [1][2]. A diretriz final E-23 da OSFI também enfatiza a adequação, a proveniência e a governança de dados corporativos para modelos [29].

Os dados de produção devem ser comparados com os dados de desenvolvimento e de teste. Mudanças na população, campos ausentes, novas categorias, sazonalidade e soluções alternativas operacionais podem enfraquecer um modelo sem alterar seu código. O desenho de monitoramento precisa de limiares de qualidade de dados e de um proprietário capaz de corrigir o processo de origem.

7. Controlar toda a cadeia de dependências de modelos e fornecedores

O sistema relevante geralmente se estende além de um único modelo. Ele pode incluir um modelo de base, embeddings, banco de dados de recuperação, camada de orquestração, filtro de segurança, regras de negócio, aplicação, serviço de nuvem, revisão humana e sistema a jusante. Um modelo operacional deve registrar a cadeia e identificar qual parte controla cada componente.

A diligência devida de fornecedores deve abranger uso pretendido, arquitetura de serviço, tratamento de dados, subprocessadores, versões do modelo, segurança, evidências de testes, termos de propriedade intelectual, confidencialidade, retenção, notificação de incidentes, níveis de serviço, direitos de auditoria, aviso de alteração, continuidade de negócios, rescisão e devolução de dados. Um nome de fornecedor de destaque não substitui a diligência devida do caso de uso.

A configuração pode alterar materialmente o comportamento. Prompts de sistema, fontes de recuperação, temperatura, ferramentas, permissões, memória, limites de ação e regras de contingência devem integrar uma gestão de mudanças controlada. Um fornecedor pode atualizar o modelo subjacente enquanto o nome da aplicação permanece inalterado. A empresa precisa de um gatilho definido para novos testes e nova aprovação.

A concentração deve ser visível no nível do portfólio. Vários fluxos de trabalho críticos podem depender de um único provedor de modelos, plataforma de nuvem ou serviço de dados. O conselho deve compreender a dependência de indisponibilidade, de precificação, contratual e estratégica, e então decidir quais alternativas, mecanismos de contingência ou procedimentos manuais são proporcionais.

Tabela 4. Evidências ao longo da cadeia de dependências de AI

O conjunto de evidências deve ser proporcional ao nível do caso de uso e à capacidade da empresa de controlar cada componente.

8. Tome decisões de construir, comprar e configurar com base na economia operacional total

A decisão de construir ou comprar deve incluir diferenciação estratégica, vantagem de dados, complexidade de integração, requisitos de controle, tempo para gerar valor, talento, infraestrutura, dependência de fornecedores e custo total do ciclo de vida. O piloto mais barato pode se tornar uma dependência operacional cara quando integração, garantia, monitoramento e mudança são incluídos.

Comprar um modelo não transfere a responsabilidade pelo caso de uso. A empresa ainda é responsável por finalidade, usuários, dados, fluxo de trabalho, decisões, monitoramento e resultado para o cliente. Construir internamente oferece maior controle sobre alguns componentes e cria obrigações de engenharia, segurança, documentação, manutenção e continuidade de talentos.

A configuração costuma ser o caminho corporativo dominante. A empresa combina modelos externos com dados proprietários, prompts, regras e fluxo de trabalho. Isso pode criar valor diferenciado sem treinar um modelo de base. Também cria um sistema cujo desempenho depende de muitos componentes mutáveis. O modelo operacional deve governar o conjunto configurado.

O caso de investimento deve distinguir a capacidade reutilizável da plataforma dos gastos específicos de cada caso de uso. Identidade, registro, avaliação, acesso seguro aos dados e orquestração podem dar suporte a vários casos. A área financeira pode alocar custos compartilhados de forma transparente, enquanto a gestão evita imputar a cada caso de uso inicial o custo de toda a plataforma.

9. Use pontos de controle do ciclo de vida que exijam evidências, e não entusiasmo

O ciclo de vida pode conter seis pontos de controle: descobrir, projetar, validar, implantar, escalar e desativar. Cada ponto de controle deve ter critérios de entrada, evidências exigidas, autoridade de decisão, aprovações condicionais e uma via de exceção com prazo definido. Um ponto de controle é encerrado quando as evidências sustentam a próxima exposição, não quando a equipe do projeto concluiu uma apresentação de slides.

A descoberta confirma o problema, o responsável e a linha de base. O design define o fluxo de trabalho, os dados, o sistema e a arquitetura de controles. A validação testa o desempenho técnico, o processo humano, a segurança e os direitos relevantes. A implantação introduz exposição controlada em produção. A escala exige evidências de que adoção, controles e benefícios permanecem sólidos em maior volume. A desativação remove acesso, dependências e dados retidos de forma controlada.

O manual do NIST fornece ações em governança, mapeamento, medição e gestão [4]. O perfil generativo AI do NIST acrescenta atenção a riscos como confabulação, integridade da informação, privacidade, segurança e propriedade intelectual [5]. O ponto de controle do ciclo de vida deve converter essas considerações em evidências do caso de uso.

A aprovação condicional pode ser valiosa quando as limitações são conhecidas e contidas. O registro deve especificar escopo, medida mitigadora, responsável, validade e evidências exigidas para renovação. Exceções sem prazo permitem que fragilidades do piloto se tornem projeto de produção permanente.

A exposição deve aumentar somente depois que as evidências e a autoridade relevantes estiverem presentes.

10. Valide o sistema no contexto em que ele operará

A validação deve testar o sistema, o fluxo de trabalho e o comportamento do usuário em relação ao uso pretendido. A avaliação técnica pode incluir precisão, confiabilidade, robustez, viés, explicabilidade, privacidade, segurança, latência e custo. A avaliação operacional deve examinar escalonamento, revisão humana, ações a jusante, casos extremos, volume de exceções e recuperação.

O conjunto de teste deve refletir a população de produção e os modos de falha materiais. O desempenho médio pode ocultar resultados ruins para eventos raros, grupos específicos de clientes ou casos de alto valor. Os limites devem estar vinculados à consequência. Um erro menor de redação e uma instrução de pagamento incorreta exigem tolerâncias diferentes.

O desafio independente deve ser proporcional. O revisor deve compreender o caso de uso, os dados, o modelo, o fluxo de trabalho e os requisitos aplicáveis, e então avaliar se as evidências sustentam a implantação. Para casos de uso de maior impacto, o revisor deve ser capaz de reproduzir testes-chave e questionar a escolha da métrica, da população, do limite e da medida mitigadora.

Sistemas generativos precisam de avaliação qualitativa e adversarial, bem como de pontuações de benchmark. Os testes podem abranger declarações sem suporte, injeção de prompt, vazamento de dados confidenciais, conteúdo prejudicial, uso indevido de ferramentas, respostas inconsistentes e comportamento de recusa. O perfil generativo AI do NIST e as orientações de desenvolvimento seguro da CISA e de parceiros internacionais fornecem pontos de referência relevantes [5][17][18].

A verdade de referência deve ser governada. Rótulos e respostas esperadas podem conter discordância entre especialistas, política desatualizada ou viés histórico. O registro de validação deve identificar quem criou os casos de teste, a data da fonte, o método de revisão, a incerteza e a cobertura populacional. Quando uma resposta exata não estiver disponível, a gestão pode avaliar se o sistema cita evidências autoritativas, expressa incerteza e encaminha para escalonamento adequadamente.

A avaliação também deve refletir frequência e custo. Um assistente de alto volume pode exigir monitoramento automatizado além de revisão especializada por amostragem. Uma decisão material rara pode justificar a revisão completa do caso. O modelo operacional deve orçar para avaliação contínua, em vez de tratar o teste de pré-produção como um custo único de projeto. As evidências de validação perdem relevância quando o modelo, os dados, o fluxo de trabalho ou a população afetada mudam.

11. Defina a supervisão humana como um desenho de decisão

A supervisão humana deve especificar quem revisa o quê, com quais informações, sob qual restrição de tempo e com qual autoridade. Uma instrução genérica para manter um humano no circuito pode falhar quando o revisor não tem expertise, tem saídas demais, evidências fracas ou incentivos para aceitar a recomendação da máquina.

O desenho pode distinguir aprovação, verificação, tratamento de exceções e recurso. Um revisor pode aprovar todos os resultados de alto impacto, amostrar saídas de baixo impacto, investigar violações de limite e fornecer um caminho de escalonamento para as partes afetadas. O revisor precisa ter acesso às evidências de origem e às limitações conhecidas, e não apenas a uma resposta polida do modelo.

O viés de automação deve ser tratado como um risco operacional. Treinamento, design de interface e amostragem de qualidade podem testar se os funcionários questionam as saídas. As substituições de decisão devem ser registradas com um motivo, para que a gestão possa distinguir julgamento saudável de prática inconsistente. Padrões repetidos de substituição de decisão podem revelar um problema de modelo, de dados ou de fluxo de trabalho.

A autoridade deve corresponder à consequência. Um usuário pode corrigir um rascunho. Um líder funcional pode suspender um fluxo de trabalho. Um responsável por riscos pode exigir um controle. O conselho ou o comitê reservado pode retirar um caso de uso material. A ação deve permanecer possível durante uma indisponibilidade ou incidente.

12. Implante por meio de produção controlada e gestão de mudanças

A implantação em produção deve usar ambientes aprovados, controles de acesso, controle de versão, registro em log, segregação de funções, reversão, planejamento de capacidade, monitoramento de serviço e registros de liberação. A decisão de implantação deve confirmar que os responsáveis operacionais, as equipes de suporte e os usuários estão prontos junto com a tecnologia.

O pacote de liberação deve identificar versões do modelo e dos componentes, configuração, fontes de dados, testes, limitações, aprovações, limites de monitoramento, contatos para incidentes e alternativa de contingência. Isso cria uma linha de base reproduzível. Uma mudança material deve acionar o subconjunto apropriado de retestes e aprovação.

A classificação de mudanças pode distinguir mudanças de rotina, significativas e emergenciais. Uma correção de redação de prompt pode seguir uma rota padrão. Uma nova permissão de ferramenta, família de modelos, fonte de dados, ação autônoma ou grupo de clientes afetado pode exigir uma nova avaliação de riscos. Mudanças emergenciais devem ser revisadas após o evento.

A implantação também deve proteger o fluxo de trabalho não AI. A alternativa de contingência manual, a continuidade do serviço e o acesso aos registros são importantes quando um provedor está indisponível ou um modelo é suspenso. A resiliência deve ser testada antes que o sistema se torne crítico.

13. Monitorar desempenho, deriva, incidentes e eficácia dos controles

O monitoramento deve seguir a hipótese do caso de uso. Medidas técnicas podem incluir acurácia, tipo de erro, calibração, deriva, latência, disponibilidade, custo de tokens ou de computação e eventos de segurança. Medidas operacionais podem incluir adoção, tempo de conclusão, retrabalho, sobrescritas, reclamações, exceções e defeitos a jusante. Medidas de benefício devem acompanhar o resultado financeiro ou de serviço controlado.

Limites precisam de ações. Um limite amarelo pode exigir investigação e escala restrita. Um limite vermelho pode exigir suspensão, reversão ou fallback manual. O responsável, o tempo de resposta e a rota de escalonamento devem ser documentados. Um painel sem lógica de ação é observação, não controle.

O gerenciamento de incidentes deve classificar danos, conter a exposição, preservar evidências, notificar partes internas e externas quando necessário, corrigir o sistema e confirmar a recuperação. Deve incluir incidentes de fornecedores e quase incidentes. As lições devem atualizar testes, limites, treinamento e padrões do portfólio.

O monitoramento deve permanecer sensível à versão. O desempenho antes de uma alteração de modelo ou dados não deve ser misturado com o desempenho depois dela. O registro deve permitir análise de coorte e explicar qual população, versão e fluxo de trabalho produziu um resultado.

Os valores são premissas hipotéticas de gestão usadas para ilustrar uma visão equilibrada de monitoramento.

14. Tornar a segurança e a resiliência parte do design do produto

Os sistemas AI criam riscos já conhecidos de software e dados, juntamente com vetores de ataque específicos de modelos. As ameaças podem envolver injeção de prompt, envenenamento de dados, acesso inseguro a ferramentas, roubo de modelo, exposição de dados sensíveis, entradas adversariais, saídas inseguras e comprometimento de dependências. A segurança deve, portanto, começar pela arquitetura e pelo uso pretendido.

O modelo de ameaças deve identificar ativos, atores, limites de confiança, interfaces e uso indevido potencial. Os controles podem incluir ambientes aprovados, privilégio mínimo, tratamento de entradas e saídas, gestão de segredos, restrições de rede, permissões de recuperação, listas de permissões de ferramentas, controles de conteúdo, registro em log, detecção de anomalias, red teaming e resposta a incidentes. O conjunto correto depende da consequência e da exposição.

Sistemas agênticos merecem atenção especial porque podem chamar ferramentas e alterar o estado externo. Permissões, limites de transação, etapas de confirmação, segregação de funções e ações reversíveis devem ser explícitos. A capacidade de um modelo de gerar um plano correto não estabelece autoridade para executá-lo.

As orientações secure-by-design da CISA, do NCSC do Reino Unido e de parceiros internacionais enfatizam a segurança em todo o design, desenvolvimento, implantação e operação [17][18]. O modelo operacional deve traduzir isso em evidências de gate e um responsável final pela segurança.

15. Integrar privacidade, propriedade intelectual e registros ao fluxo de trabalho

A análise de privacidade deve seguir o fluxo real de dados e as pessoas afetadas. A gestão deve entender quais dados pessoais entram em prompts, sistemas de recuperação, logs e saídas; para onde viajam; quem pode acessá-los; quanto tempo permanecem; e como os direitos podem ser exercidos. Mudanças de finalidade e uso de decisões automatizadas podem exigir análise adicional.

Os controles de propriedade intelectual devem abranger insumos, dados de treinamento ou ajuste fino, resultados gerados, termos de fornecedores, componentes de código aberto, trabalho de funcionários e material de clientes. A empresa deve definir quando o conteúdo gerado pode ser publicado, incorporado a produtos, usado como base para consultoria ou compartilhado externamente.

A política de registros deve preservar decisões e evidências, respeitando os limites de retenção. Aprovações relevantes, testes, versões de modelos, prompts ou configurações, exceções, incidentes e validação de benefícios podem exigir retenção controlada. Dados conversacionais rotineiros podem ter um cronograma diferente.

A Lei AI da UE, as orientações de transparência relacionadas, as orientações do Reino Unido sobre proteção de dados, UAE e os referenciais éticos sauditas e os materiais de governança de Singapura ilustram a importância crescente da rastreabilidade, da transparência e do uso passível de responsabilização [9][11][15][20][21][22][25][26]. A aplicabilidade e o efeito jurídico dependem do sistema, do papel e da jurisdição específicos.

16. Construa o caso de benefícios a partir de uma linha de base controlada e de um contrafactual

O acompanhamento de benefícios começa antes da implantação. O charter deve registrar o processo atual, volume, mão de obra, custo, tempo de ciclo, qualidade, conversão, nível de serviço e resultado de risco. Também deve definir o contrafactual: o que a administração espera sem a intervenção. Uma simples comparação de antes e depois pode atribuir erroneamente crescimento de mercado, precificação, dimensionamento de equipe ou mudanças de processo a AI.

Cada benefício deve ter uma fórmula, fonte de dados, frequência, responsável e método de validação. O tempo economizado só se torna valor financeiro quando a empresa altera capacidade, custo, vazão ou serviço. Uma redução prevista no tempo de processamento pode ser operacionalmente útil. Ela não deve ser apresentada como EBITDA até que a ponte para alocação de pessoal, produção ou gasto evitado seja comprovada.

Os benefícios de receita exigem disciplina semelhante. Um processo de vendas assistido por AI pode influenciar a qualidade dos leads, a conversão, o preço, a retenção ou a capacidade dos representantes. A empresa deve identificar o mecanismo, comparar coortes quando viável, controlar outras mudanças e evitar contar a mesma receita em várias iniciativas.

A visão de custo total deve incluir licenças, computação, implementação, integração, preparação de dados, asseguração, segurança, treinamento, suporte, gestão de mudanças e monitoramento contínuo. O custo de plataforma compartilhada deve ser alocado de forma consistente. O custo de saída e a sensibilidade a preços do fornecedor devem constar do caso.

A atribuição pode utilizar vários desenhos. Uma implantação aleatorizada pode fornecer evidências fortes quando for ética e operacionalmente viável. Implementação faseada, coortes emparelhadas, séries temporais interrompidas ou decomposição no nível do processo podem ser mais adequadas em outros contextos. O método escolhido deve ser declarado antes da revisão dos resultados, com limitações e mudanças concorrentes registradas. A administração deve resistir à seleção do método que produz o número mais favorável depois do fato.

Os benefícios podem ser resultados financeiros, de serviço, de risco ou de capacidade. Não devem ser forçados a uma estimativa monetária quando as evidências não a sustentam. Uma redução controlada na variabilidade da resposta ou uma rastreabilidade aprimorada podem ser relevantes para o conselho de administração, mesmo quando a área financeira não consegue validar um efeito imediato no P&L. O registro pode mostrar o resultado operacional e sua relevância para a decisão, preservando a fronteira em torno do valor financeiro.

As orientações sobre benefícios no setor público fornecem um princípio geral útil: os benefícios devem ser identificados, definidos, acompanhados, realizados e sustentados ao longo do ciclo de vida, com responsáveis sujeitos à prestação de contas e asseguração [31][32]. A mesma disciplina melhora a alocação de capital em empresas privadas.

Tabela 5. Registro controlado de benefícios de AI

Valores projetados, observados e validados pela área financeira devem permanecer separados.

17. Converta evidências operacionais em uma ponte de DRE, caixa e valor

A área financeira deve manter uma ponte do benefício operacional bruto até o resultado econômico validado. Comece pela variação observada de resultado ou desempenho. Remova efeitos de volume, mix, preço, mercado e outros efeitos concorrentes. Deduza custo recorrente, amortização de implementação quando aplicável, custo incremental de controle e deslocamento. Identifique se o resultado chega a receita, margem bruta, despesa operacional, capital de giro, despesa de capital ou risco.

O tratamento contábil deve permanecer separado da mensuração de benefícios pela gestão. O IAS 38 contém critérios de reconhecimento para ativos intangíveis, e o IASB continuou a examinar questões envolvendo dados e soluções relacionados a AI [33]. A gestão deve obter orientação contábil em vez de presumir que um investimento ou benefício descrito internamente determina o tratamento nas demonstrações financeiras.

A ponte de benefícios deve usar visões de período, acumulada e de run rate. Um caso de uso pode criar um ônus único de implementação, um custo recorrente e um benefício recorrente posterior. O momento do caixa pode diferir da despesa contábil. O conselho precisa das três dimensões para alocar capital.

A confiança da previsão deve ser explícita. Um intervalo com direcionadores definidos é mais útil para a decisão do que um único número preciso baseado em premissas fracas de adoção. Análises de sensibilidade podem mostrar adoção por usuários, volume de tarefas, preço do fornecedor, taxa de erro e tempo até escala.

Os valores são premissas hipotéticas da gestão e não representam um resultado ou previsão de cliente.

18. Trate a adoção e o redesenho do fluxo de trabalho como parte do investimento

O benefício de AI depende de o trabalho mudar. A adoção deve ser definida como uso correto no fluxo de trabalho pretendido, e não como atividade de login ou de licença. A empresa deve saber quem usa o sistema, para quais tarefas, com qual revisão e se o resultado altera a decisão subsequente.

O redesenho do fluxo de trabalho pode eliminar transferências entre etapas, alterar limites de funções e criar novas etapas de controle. Também pode expor trabalho oculto anteriormente absorvido pelos funcionários. O mapeamento de processos deve identificar para onde o tempo se desloca, quais filas desaparecem, quais exceções crescem e quais habilidades se tornam mais valiosas.

O treinamento deve ser específico por função e caso de uso. Os usuários precisam de propósito, limites, regras de dados, expectativas de revisão, escalonamento, exemplos e limitações conhecidas. Os gestores precisam interpretar evidências de monitoramento e de benefícios. As equipes técnicas e de controle precisam de responsabilidades ao longo do ciclo de vida. Os membros do conselho precisam da economia do portfólio e da exposição material.

O plano de força de trabalho deve abordar capacidade em vez de presumir redução imediata de custos. O tempo liberado pode apoiar crescimento de volume, serviço, qualidade ou evitar aumento de quadro de pessoal. O efeito econômico realizado depende da ação da gestão. Consultas a funcionários e requisitos locais de emprego também podem se aplicar.

19. Alocar capital por meio de etapas de decisão do portfólio

O portfólio deve competir por capital, dados, engenharia, capacidade de controle e atenção da gestão, que são escassos. Uma estrutura comum de pontuação pode comparar relevância estratégica, valor endereçável, qualidade das evidências, tempo até o impacto, reutilização, risco, dependência e carga de implementação. As pontuações informam o julgamento e não devem automatizar a decisão de investimento.

O financiamento pode ser escalonado. A descoberta recebe um pequeno orçamento de evidências. A validação recebe recursos depois que a linha de base e a arquitetura são críveis. O financiamento de produção segue testes bem-sucedidos e prontidão dos controles. O financiamento de escala segue a adoção e evidências iniciais de benefícios. Isso reduz a escalada de custos irrecuperáveis.

A revisão do portfólio deve identificar decisões de encerramento. Um caso de uso pode ser tecnicamente bem-sucedido e economicamente pouco atrativo. Outro pode continuar valioso, mas exigir um fornecedor ou fluxo de trabalho diferente. O capital deve ser realocado quando as evidências mudarem.

Plataformas compartilhadas precisam de governança separada. Identidade, acesso a dados, avaliação, monitoramento e gateways de modelo podem reduzir o custo marginal em todo o portfólio. Seu valor pode ser medido por meio de casos de uso habilitados, duplicação evitada e qualidade dos controles, juntamente com custo de serviço e risco de concentração.

A revisão de capital deve considerar o valor do aprendizado. Um experimento delimitado pode merecer financiamento porque resolve uma incerteza material sobre dados, adoção, resposta do cliente ou viabilidade técnica. O registro da decisão deve indicar a incerteza, as evidências buscadas, a exposição máxima e a data até a qual a gestão irá escalar, redesenhar ou interromper. Isso trata a experimentação como uma opção adquirida com vencimento definido, e não como um piloto indefinido.

O portfólio também deve reconhecer gargalos. Dez casos de uso financiados podem competir por um único responsável pelos dados, revisor de segurança ou equipe de fluxo de trabalho, atrasando todos eles. O planejamento de capacidade deve sequenciar o trabalho em torno da capacidade escassa que determina a vazão. O conselho pode então decidir se adiciona capacidade, restringe o portfólio ou altera a arquitetura.

20. Aplicar camadas complementares de jurisdição e setor sem fragmentar o núcleo

A empresa pode manter um modelo operacional central e anexar camadas complementares para entidade legal, geografia, setor e caso de uso. O núcleo contém inventário, propriedade, classificação em níveis, ciclo de vida, evidências, monitoramento e benefícios. Uma camada complementar acrescenta direitos aplicáveis, aprovações, registros, divulgações, testes ou expectativas supervisoras.

A Lei de AI da UE usa uma estrutura baseada em risco com obrigações que variam conforme o sistema e o ator; a fiscalização e o momento de aplicação continuaram a evoluir [9][10][11][12]. As autoridades do Reino Unido usam princípios intersetoriais ao lado dos reguladores existentes, enquanto a PRA aplica expectativas de risco de modelo a empresas especificadas [14][16]. As fontes dos EUA incluem estruturas voluntárias do NIST, regras setoriais e fiscalização contra alegações não comprovadas [3][5][19].

O UAE e a Arábia Saudita publicam orientações de ética e governança que enfatizam responsabilização, transparência, privacidade, segurança e adoção responsável [20][21][22][23]. O trabalho FREE-AI do RBI da Índia aborda AI responsável em finanças [24]. As estruturas de governança de Cingapura e o programa AI Verify apoiam testes práticos e implantação responsável [25][26]. A ASIC identificou lacunas entre a adoção de AI e a governança entre os licenciados revisados [27]. A OSFI do Canadá finalizou uma diretriz ampla de risco de modelo para todo o ciclo de vida, com considerações de AI e data de vigência em 2027 [29][30].

Essas fontes diferem em status legal, escopo e cronograma. O modelo operacional deve registrar a aplicabilidade e as orientações para cada caso de uso. Uma declaração de política global não deve substituir uma análise jurídica local.

Arquitetura transfronteiriça exige uma visão operacional da localização dos dados, acesso remoto, processamento por fornecedores, equipes de suporte, notificação de incidentes e acesso regulatório. Um contrato pode identificar uma região de serviço enquanto telemetria, suporte humano ou subprocessadores operam em outro local. O registro do fluxo de dados deve refletir o processamento real e deve ser atualizado quando o serviço mudar.

Camadas complementares setoriais podem adicionar controles sem criar um sistema empresarial separado. Um caso de uso financeiro pode exigir evidências de risco de modelo, conduta e resultados para o cliente. Um caso de uso de saúde, emprego, segurança ou infraestrutura crítica pode exigir análises distintas de aspectos profissionais, direitos e resiliência. O inventário comum e a estrutura de etapas de decisão preservam a visibilidade do portfólio, enquanto a camada complementar preserva a responsabilização específica do domínio.

21. Testar a estrutura por meio de um caso hipotético de operação de serviços

Considere uma empresa hipotética do portfólio que processa 240.000 solicitações de atendimento ao cliente por ano. A administração propõe um assistente que recupera conhecimento aprovado, redige uma resposta e recomenda um código de roteamento. Os funcionários continuam responsáveis pela revisão e pelo envio. A empresa espera menor tempo de atendimento e menos retrabalho.

A descoberta estabelece o fluxo de trabalho atual: tempo mediano de atendimento, revisão de qualidade, contatos repetidos, taxa de reclamações, fila, composição da mão de obra e volume sazonal. O termo de abertura identifica operações de clientes como responsável de negócio, tecnologia como responsável do sistema, a equipe de conhecimento como responsável pelos dados e finanças como validadora dos benefícios. Dados pessoais e confidenciais são mapeados antes do desenho.

O caso de uso é classificado na camada intermediária porque os resultados chegam aos clientes e podem afetar o serviço ou direitos, enquanto funcionários treinados mantêm a aprovação. A validação usa casos representativos, categorias difíceis, prompts adversariais e um teste separado de permissões de recuperação. A empresa define limiares para sustentação factual, precisão de roteamento, tratamento de dados confidenciais, qualidade da revisão e resultados de reclamações.

O piloto inicial mostra uma redução hipotética de 24% no tempo de atendimento para solicitações elegíveis. Apenas 58% das solicitações são elegíveis, e a adoção chega a 70% do volume elegível. A administração, portanto, evita aplicar 24% à base de custos total. Finanças modela a capacidade realizada a partir do volume elegível real, da adoção, do retrabalho e do custo incremental de operação.

A aprovação para escala depende de atualização controlada do conhecimento, treinamento de usuários, estabilidade dos limiares e um plano de força de trabalho para a capacidade liberada. O conselho recebe benefícios previstos, observados e validados separadamente. Nenhum valor é atribuído ao modelo simplesmente porque ele foi implantado.

22. Dê ao conselho um pacote de decisão, e não um relatório de atividades de AI

O pacote do conselho deve mostrar exposição do portfólio, decisões e evidências. Um painel de uma página pode incluir casos de uso por camada e ciclo de vida, capital comprometido, valor previsto e validado, adoção, dependências materiais, exceções de controle, incidentes, revisões atrasadas e decisões necessárias. Os detalhes ficam por trás do painel.

Todo caso de uso material deve mostrar responsável, resultado pretendido, estágio, camada de risco, evidência mais recente, limitação não resolvida, próxima etapa de decisão e status do benefício. Os benefícios devem ser separados em valores previstos, observados e validados por finanças. Os custos devem incluir visões de custo comprometido, incorrido e recorrente.

A narrativa importa quando as métricas mudam. A administração deve explicar por que adoção, desempenho do modelo, limiares de controle ou valor mudaram; qual decisão se seguiu; e quem é responsável pela ação. O pacote deve preservar consistência de versão e período.

O conselho também deve ver concentração: fluxos de trabalho críticos por fornecedor, nuvem, fonte de dados e pessoa-chave. Isso conecta a supervisão de AI à resiliência operacional, ao risco cibernético, às compras e à sucessão.

A asseguração deve ser visível como um mapa de cobertura. Auditoria interna, risco, compliance, segurança, privacidade, finanças e especialistas externos podem testar, cada um, uma parte do sistema. O conselho deve ver quais afirmações materiais foram revisadas, o período e o escopo, achados não resolvidos e a resposta da administração. Múltiplas revisões não criam asseguração completa quando examinam o mesmo controle restrito e deixam intocadas a responsabilização, a adoção ou a atribuição de benefícios.

As informações para o conselho devem amadurecer com o portfólio. Pacotes iniciais podem enfatizar a completude do inventário, o apetite e o desenho das etapas de decisão. Um portfólio em escala deve enfatizar desempenho em produção, incidentes, concentração e valor validado. Um portfólio maduro também deve mostrar descontinuação, eficiência de controle e se a capacidade compartilhada está reduzindo o custo marginal. A arquitetura de informações deve mudar quando as decisões do conselho mudarem.

Tabela 6. Scorecard do modelo operacional de AI do conselho

Cada linha deve levar a uma decisão, escalonamento ou ação operacional confirmada.

23. Implementar o modelo operacional em cem dias

Os primeiros trinta dias estabelecem visibilidade e autoridade. Nomeie o patrocinador executivo, aprove o apetite provisório, identifique casos de uso e ferramentas relevantes, defina o inventário, atribua responsáveis e interrompa qualquer atividade fora de limites claros. Finanças seleciona um pequeno número de linhas de base de benefícios prioritários.

Dos dias trinta e um aos sessenta, construa a estrutura central de controles. Defina níveis de risco, pontos de decisão do ciclo de vida, evidências mínimas, classificação de mudanças, fluxo de incidentes, requisitos de fornecedores e registro de benefícios. Selecione dois ou três casos de uso prioritários que sejam comercialmente relevantes e suficientemente delimitados para testar o sistema.

Dos dias sessenta e um aos noventa, execute o primeiro ciclo controlado. Conclua o design, o mapeamento de dados, a validação, a revisão de segurança, o treinamento de usuários e a prontidão para produção dos casos selecionados. Registre aprovações condicionais e exceções. Estabeleça monitoramento e uma ponte de benefícios sob responsabilidade de Finanças.

Dos dias noventa e um aos cem, encerre o primeiro ciclo do conselho. Apresente o inventário, a exposição, as evidências, os primeiros resultados operacionais, a confiança nos benefícios, as decisões e a alocação de capital do próximo trimestre. O modelo operacional só se torna rotina quando governança, entrega e finanças usam os mesmos registros.

O prazo é ilustrativo e deve ser ampliado quando a consequência sistêmica, a regulamentação ou a prontidão organizacional assim exigirem.

Referências

1. OCDE, Princípios de AI da OCDE, atualizado em 2024, https://www.oecd.org/en/topics/ai-principles.html
2. OCDE, AI, Governança e Privacidade de Dados: Sinergias e Áreas de Cooperação Internacional, 2024, https://www.oecd.org/content/dam/oecd/en/publications/reports/2024/06/ai-data-governance-and-privacy_2ac13a42/2476b1a4-en.pdf
3. Instituto Nacional de Padrões e Tecnologia, Estrutura de Gestão de Riscos de Inteligência Artificial 1.0, 2023, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
4. Instituto Nacional de Padrões e Tecnologia, Playbook do RMF de AI, atualizado em 2026, https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook
5. Instituto Nacional de Padrões e Tecnologia, Estrutura de Gestão de Riscos de Inteligência Artificial: Perfil de Inteligência Artificial Generativa, 2024, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
6. Instituto Nacional de Padrões e Tecnologia, Centro de Recursos para AI Confiável e Responsável, 2026, https://airc.nist.gov/
7. Organização Internacional para Padronização, ISO/IEC 42001:2023 Sistema de Gestão de Inteligência Artificial, 2023, https://www.iso.org/standard/42001.html
8. Organização Internacional para Padronização, ISO/IEC 23894:2023 Gestão de Riscos de Inteligência Artificial, 2023, https://www.iso.org/standard/77304.html
9. Comissão Europeia, Lei AI: Marco Regulatório para Inteligência Artificial, atualizado em 2026, https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
10. Comissão Europeia, O Marco de Aplicação da Lei AI, 2026, https://digital-strategy.ec.europa.eu/en/policies/enforcement-ai-act
11. Comissão Europeia, Diretrizes sobre Obrigações de Transparência para Fornecedores e Implantadores de Determinados Sistemas de AI, 2026, https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-transparency-obligations
12. Comissão Europeia, Diretrizes sobre Obrigações para Fornecedores de AI de Uso Geral, 2025, https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers
13. EUR-Lex, Regulamento (UE) 2016/679, Regulamento Geral sobre a Proteção de Dados, 2016, https://eur-lex.europa.eu/eli/reg/2016/679/oj
14. Governo do Reino Unido, Implementação dos Princípios Regulatórios de AI do Reino Unido: Orientações para Reguladores, 2024, https://assets.publishing.service.gov.uk/media/65c0b6bd63a23d0013c821a0/implementing_the_uk_ai_regulatory_principles_guidance_for_regulators.pdf
15. Escritório do Comissário de Informação, Orientações sobre AI e Proteção de Dados, atualizado em 2023, https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/
16. Banco da Inglaterra, Autoridade de Regulação Prudencial, SS1/23 Princípios de Gestão de Risco de Modelos para Bancos, atualizado em 2026, https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss
17. Agência de Segurança Cibernética e de Infraestrutura e Centro Nacional de Segurança Cibernética do Reino Unido, Diretrizes para o Desenvolvimento Seguro de Sistemas AI, 2023, https://www.cisa.gov/news-events/alerts/2023/11/26/cisa-and-uk-ncsc-unveil-joint-guidelines-secure-ai-system-development
18. Agência de Segurança Cibernética e de Infraestrutura, Escolha de Tecnologias Seguras e Verificáveis, 2024, https://www.cisa.gov/resources-tools/resources/choosing-secure-and-verifiable-technologies
19. Comissão Federal de Comércio, Inteligência Artificial: Aplicação e Orientação Empresarial, atualizado em 2026, https://www.ftc.gov/industry/technology/artificial-intelligence
20. UAE Gabinete do Ministro de Estado para Inteligência Artificial, Economia Digital e Aplicações de Trabalho Remoto, UAE Posição sobre a Política de AI, 2024, https://ai.gov.ae/wp-content/uploads/2024/10/UAE-Guiding-on-ai-policy-EN-V3.pdf
21. UAE Gabinete de Inteligência Artificial, AI Princípios e Diretrizes de Ética, 2022, https://ai.gov.ae/wp-content/uploads/2023/05/MOCAI-AI-Ethics-EN.pdf
22. Autoridade Saudita de Dados e Inteligência Artificial, AI Princípios de Ética, https://sdaia.gov.sa/en/SDAIA/about/Documents/ai-principles.pdf
23. Autoridade Saudita de Dados e Inteligência Artificial, Regulamentos e Políticas, atualizado em 2026, https://sdaia.gov.sa/en/SDAIA/about/Pages/RegulationsAndPolicies.aspx
24. Banco Central da Índia, Relatório do Comitê FREE-AI: Estrutura para Habilitação Responsável e Ética da Inteligência Artificial, 2025, https://www.rbi.org.in/Scripts/PublicationReportDetails.aspx?UrlPage=&ID=1299
25. Comissão de Proteção de Dados Pessoais de Singapura, Estrutura Modelo de Governança de Inteligência Artificial, 2020, https://www.pdpc.gov.sg/help-and-resources/2020/01/model-ai-governance-framework
26. Autoridade de Desenvolvimento de Infocomunicações e Mídia de Singapura, Estrutura Modelo de Governança AI para AI Generativa, 2024, https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2024/model-ai-governance-framework-for-generative-ai
27. Comissão Australiana de Valores Mobiliários e Investimentos, REP 798 Cuidado com a Lacuna: Arranjos de Governança diante da Inovação em AI, 2024, https://asic.gov.au/regulatory-resources/find-a-document/reports/rep-798-beware-the-gap-governance-arrangements-in-the-face-of-ai-innovation/
28. Autoridade Australiana de Regulação Prudencial, CPS 230 Gestão de Risco Operacional, atualizado em 2026, https://www.apra.gov.au/standards/cps-230
29. Escritório do Superintendente de Instituições Financeiras do Canadá, Diretriz E-23 Gestão de Risco de Modelos, 2025, https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/guideline-e-23-model-risk-management-2027
30. Escritório do Superintendente de Instituições Financeiras do Canadá e Agência Financeira de Consumo do Canadá, Usos e Riscos de AI em Instituições Financeiras Reguladas Federalmente, 2024, https://www.osfi-bsif.gc.ca/en/about-osfi/reports-publications/osfi-fcac-risk-report-ai-uses-risks-federally-regulated-financial-institutions
31. Autoridade de Infraestrutura e Projetos do Reino Unido e Gabinete do Governo, Guia para Gestão Eficaz de Benefícios em Grandes Projetos, 2017, https://www.gov.uk/government/publications/guide-for-effective-benefits-management-in-major-projects
32. Governo do Reino Unido, Estrutura de Eficiência Governamental, 2025, https://www.gov.uk/government/publications/the-government-efficiency-framework/the-government-efficiency-framework--2
33. Fundação IFRS, Ativos Intangíveis: Outros casos de teste potenciais, incluindo recursos de dados e dados e soluções relacionados à inteligência artificial, 2026, https://www.ifrs.org/content/dam/ifrs/meetings/2026/january/iasb/ap17d-other-potential-test-cases-data-ai.pdf

Fontes e leitura adicional

1. OCDE, Princípios de AI da OCDE, atualizado em 2024, Fonte oficial
2. OCDE, AI, Governança e Privacidade de Dados: Sinergias e Áreas de Cooperação Internacional, 2024, Fonte oficial
3. Instituto Nacional de Padrões e Tecnologia, Estrutura de Gestão de Riscos de Inteligência Artificial 1.0, 2023, Fonte oficial
4. Instituto Nacional de Padrões e Tecnologia, Playbook do RMF de AI, atualizado em 2026, Fonte oficial
5. Instituto Nacional de Padrões e Tecnologia, Estrutura de Gestão de Riscos de Inteligência Artificial: Perfil de Inteligência Artificial Generativa, 2024, Fonte oficial
6. Instituto Nacional de Padrões e Tecnologia, Centro de Recursos para AI Confiável e Responsável, 2026, Fonte oficial
7. Organização Internacional para Padronização, ISO/IEC 42001:2023 Sistema de Gestão de Inteligência Artificial, 2023, Fonte oficial
8. Organização Internacional para Padronização, ISO/IEC 23894:2023 Gestão de Riscos de Inteligência Artificial, 2023, Fonte oficial
9. Comissão Europeia, Lei AI: Marco Regulatório para Inteligência Artificial, atualizado em 2026, Fonte oficial
10. Comissão Europeia, O Marco de Aplicação da Lei AI, 2026, Fonte oficial
11. Comissão Europeia, Diretrizes sobre Obrigações de Transparência para Fornecedores e Implantadores de Determinados Sistemas de AI, 2026, Fonte oficial
12. Comissão Europeia, Diretrizes sobre Obrigações para Fornecedores de AI de Uso Geral, 2025, Fonte oficial
13. EUR-Lex, Regulamento (UE) 2016/679, Regulamento Geral sobre a Proteção de Dados, 2016, Fonte oficial
14. Governo do Reino Unido, Implementação dos Princípios Regulatórios de AI do Reino Unido: Orientações para Reguladores, 2024, Fonte oficial
15. Escritório do Comissário de Informação, Orientações sobre AI e Proteção de Dados, atualizado em 2023, Fonte oficial
16. Banco da Inglaterra, Autoridade de Regulação Prudencial, SS1/23 Princípios de Gestão de Risco de Modelos para Bancos, atualizado em 2026, Fonte oficial
17. Agência de Segurança Cibernética e de Infraestrutura e Centro Nacional de Segurança Cibernética do Reino Unido, Diretrizes para o Desenvolvimento Seguro de Sistemas AI, 2023, Fonte oficial
18. Agência de Segurança Cibernética e de Infraestrutura, Escolha de Tecnologias Seguras e Verificáveis, 2024, Fonte oficial
19. Comissão Federal de Comércio, Inteligência Artificial: Aplicação e Orientação Empresarial, atualizado em 2026, Fonte oficial
20. UAE Gabinete do Ministro de Estado para Inteligência Artificial, Economia Digital e Aplicações de Trabalho Remoto, UAE Posição sobre a Política de AI, 2024, Fonte oficial
21. UAE Gabinete de Inteligência Artificial, AI Princípios e Diretrizes de Ética, 2022, Fonte oficial
22. Autoridade Saudita de Dados e Inteligência Artificial, AI Princípios de Ética, Fonte oficial
23. Autoridade Saudita de Dados e Inteligência Artificial, Regulamentos e Políticas, atualizado em 2026, Fonte oficial
24. Banco Central da Índia, Relatório do Comitê FREE-AI: Estrutura para Habilitação Responsável e Ética da Inteligência Artificial, 2025, Fonte oficial
25. Comissão de Proteção de Dados Pessoais de Singapura, Estrutura Modelo de Governança de Inteligência Artificial, 2020, Fonte oficial
26. Autoridade de Desenvolvimento de Infocomunicações e Mídia de Singapura, Estrutura Modelo de Governança AI para AI Generativa, 2024, Fonte oficial
27. Comissão Australiana de Valores Mobiliários e Investimentos, REP 798 Cuidado com a Lacuna: Arranjos de Governança diante da Inovação em AI, 2024, Fonte oficial
28. Autoridade Australiana de Regulação Prudencial, CPS 230 Gestão de Risco Operacional, atualizado em 2026, Fonte oficial
29. Escritório do Superintendente de Instituições Financeiras do Canadá, Diretriz E-23 Gestão de Risco de Modelos, 2025, Fonte oficial
30. Escritório do Superintendente de Instituições Financeiras do Canadá e Agência Financeira de Consumo do Canadá, Usos e Riscos de AI em Instituições Financeiras Reguladas Federalmente, 2024, Fonte oficial
31. Autoridade de Infraestrutura e Projetos do Reino Unido e Gabinete do Governo, Guia para Gestão Eficaz de Benefícios em Grandes Projetos, 2017, Fonte oficial
32. Governo do Reino Unido, Estrutura de Eficiência Governamental, 2025, Fonte oficial
33. Fundação IFRS, Ativos Intangíveis: Outros casos de teste potenciais, incluindo recursos de dados e dados e soluções relacionados à inteligência artificial, 2026, Fonte oficial