AI Diligência de benchmark: Reproduzindo alegações sobre modelo e produto antes da assinatura

1. Converta toda alegação de benchmark em uma proposição testável

Uma alegação de benchmark deve identificar o sistema, a tarefa, a população, a intervenção, o comparador, a métrica e a relevância para a decisão. A afirmação de que um modelo é mais preciso do que um concorrente é incompleta até que o comprador saiba qual checkpoint do modelo, política de prompts, configuração de ferramentas, conjunto de dados, exclusões, regra de pontuação e intervalo de confiança produziram o resultado. A afirmação de que uma aplicação é mais rápida ou mais barata é incompleta até que concorrência, hardware, cache, novas tentativas, revisão humana e tratamento de falhas sejam incluídos.

O registro de diligência devida deve preservar a redação exata apresentada a clientes, investidores e ao comitê de transação. Cada alegação deve vincular-se a código-fonte, pesos ou versão API, dados de avaliação, logs de execução, hardware, dependências de software, implementação da métrica, notebooks de analistas e aprovações. As evidências devem reter carimbos de data/hora e hashes quando praticável. Um número de apresentação que não pode ser rastreado até uma execução reproduzível deve permanecer em um estado não resolvido.

As alegações também devem ter uma finalidade na transação. Um resultado pode sustentar diferenciação de produto, retenção de clientes, poder de precificação, margem bruta, prontidão regulatória ou um pagamento contingente. A força exigida do teste depende desse uso. Uma comparação de marketing pode exigir correção sem alterar o valor. Uma capacidade alegada que sustenta a maior parte da projeção pode exigir uma avaliação cega independente e uma reparação contratual antes da assinatura.

2. Construir um grafo de evidências de benchmark

O grafo de evidências conecta a pontuação reportada aos artefatos e às decisões que a produziram. Os nós representam o modelo, o conjunto de dados, a tarefa, o prompt, a ferramenta, o hardware, a versão de software, a métrica, a exclusão, o avaliador humano, a execução e a alegação publicada. As arestas registram dependências e transformações. O grafo deve permitir que um revisor vá de um número em slide do conselho de volta aos resultados brutos e avance até a premissa comercial que ele sustenta.

Cada nó precisa de um estado de evidência: preservado e verificado, preservado mas não verificado, representação da administração, registro de terceiros, indisponível ou substituído. Um hash estabelece a identidade do arquivo, mas não estabelece que o arquivo esteja completo, adequado ou livre de contaminação. Os revisores devem, portanto, registrar tanto a proveniência quanto a adequação ao propósito.

O grafo expõe substituições silenciosas. Uma alegação pública pode citar um benchmark enquanto o notebook de avaliação usa uma divisão modificada. O produto pode chamar um modelo mais novo do que o descrito na diligência devida. Um gráfico de latência pode omitir solicitações com falha. A reconciliação assistida por máquina pode sinalizar identificadores, datas, contagens de amostras e versões divergentes para revisão especializada. O grafo resultante passa a ser a superfície de controle para reprodução, exceções e tratamento da transação.

Uma alegação relevante para a transação deve ser rastreável desde os artefatos de origem, passando pela avaliação, até a premissa comercial.

Tabela 1. Registro mínimo da alegação de benchmark

O registro separa identidade, método, resultado e uso na transação.

3. Defina a decisão antes de escolher o teste

O desenho da avaliação deve começar pela decisão da transação. Um comprador que decide se um produto atende a um limiar contratual de acurácia precisa de uma população representativa de clientes, da métrica contratual e do tratamento acordado para falhas. Um comprador que avalia a margem bruta precisa de throughput, hardware, custo de inferência, revisão humana e carga de suporte. Um conselho que avalia a diferenciação técnica precisa de comparadores relevantes e de evidências de que a vantagem persiste fora de uma demonstração preparada.

Um benchmark raramente responde a todas essas perguntas. Testes de capacidade medem o desempenho em tarefas definidas. Testes de robustez variam entradas e condições operacionais. Testes de segurança investigam comportamentos nocivos ou que violam políticas. Testes econômicos conectam qualidade a latência, computação, mão de obra e níveis de serviço. Testes de produto incorporam a interface, a recuperação, as ferramentas, o fluxo de trabalho e a escalada humana. O plano de diligência devida deve indicar qual pergunta cada teste responde e qual pergunta ele não consegue responder.

A equipe deve concordar com a materialidade antes de ver os resultados reproduzidos. A materialidade pode envolver concentração de receita, penalidades contratuais, margem projetada, uso regulamentado, danos ao cliente, necessidades de capital ou avaliação. Uma regra de decisão pré-registrada reduz a tentação de redefinir o sucesso após um resultado inconveniente. Ela também ajuda o vendedor a fornecer os artefatos corretos e protege o comprador de gastar tempo com pontuações de pouca consequência para a transação.

4. Congele o sistema objeto da alegação e o ambiente de avaliação

A reprodução exige um objeto identificado. A equipe de diligência devida deve congelar o checkpoint do modelo ou a versão API, o prompt do sistema, o corpus de recuperação, as definições de ferramentas, as camadas de segurança, os parâmetros de amostragem, os pacotes de software, o perfil de hardware e o código de avaliação. Contêineres, bloqueios de dependências, hashes e manifestos de execução podem apoiar o congelamento. Quando um API de terceiros impedir a preservação total, a equipe deve registrar provedor, endpoint, identificador do modelo, data, região e metadados das respostas observadas.

O sistema congelado deve refletir a alegação objeto de diligência. Um vendedor pode demonstrar um checkpoint de pesquisa enquanto os clientes usam uma pilha de produtos otimizada. Ambos podem merecer testes, mas os resultados devem permanecer distintos. Ajuste fino, recuperação, pós-processamento e revisão humana podem criar valor que não reside no modelo base. O comprador deve evitar atribuir o desempenho do produto à capacidade proprietária do modelo quando a vantagem vem de um componente externo substituível.

Os controles de acesso importam. O ambiente de reprodução pode conter código confidencial, dados de clientes e pesos do modelo. A equipe limpa deve registrar usuários, transferências de dados, execuções e exportações. As evidências de reprodução devem permanecer disponíveis após a assinatura, respeitando licenças, privacidade, segredos comerciais e segurança. A assessoria jurídica e os especialistas em segurança devem definir o acesso permitido, a retenção e a destruição.

5. Reconstrua a linhagem do conjunto de dados e a população pretendida

A linhagem do conjunto de dados deve descrever de onde os exemplos se originaram, como foram coletados, filtrados, rotulados, deduplicados e divididos, e quais versões entraram em treinamento, ajuste e avaliação. O comprador precisa de identificadores no nível do item ou substitutos defensáveis para testar sobreposição. Declarações agregadas sobre dados proprietários oferecem garantia limitada quando a avaliação depende da vantagem de dados.

A população de avaliação deve corresponder à alegação comercial. Um fluxo de trabalho médico, decisão de crédito, inspeção industrial ou ferramenta de redação jurídica pode enfrentar mix de casos, idioma, geografia, prevalência e comportamento do usuário diferentes de um benchmark público. O desempenho pode mudar quando casos raros, mas custosos, recebem maior peso. A equipe de diligência devida deve comparar as distribuições do benchmark com o uso real ou contratado e documentar a lacuna de cobertura.

Licenciamento e consentimento exigem revisão separada. Um conjunto de dados pode ser estatisticamente útil ao mesmo tempo que cria exposição contratual, de privacidade, de propriedade intelectual ou regulatória. O registro do benchmark deve vincular proveniência, uso permitido, retenção e restrições de transferência. Assessores qualificados devem avaliar as obrigações aplicáveis. A reprodução técnica não pode sanar um direito que a empresa-alvo não possui.

6. Testar sobreposição direta entre treino e teste

A sobreposição direta ocorre quando itens de avaliação, respostas ou duplicatas próximas aparecem no material de treinamento ou ajuste. Isso pode inflar a generalização aparente porque o modelo encontrou o teste. A detecção pode combinar hashes exatos, correspondência de texto canonizado, sobreposição de n-gramas, similaridade semântica, impressões digitais de imagens e metadados. O método deve considerar mudanças de formatação, traduções, paráfrases e exemplos derivados.

Uma correspondência precisa ser interpretada. Conhecimento amplamente publicado pode aparecer legitimamente em diferentes fontes, enquanto um par distinto de pergunta e resposta de benchmark gera uma preocupação mais forte. A equipe deve registrar a força da correspondência, a direção, o momento e se o item pode ter influenciado o treinamento. Quando o vendedor não pode expor os dados de treinamento, alternativas incluem atestações, registros de geração de dados, pesquisa de inferência de pertencimento, itens canário e novos testes sequestrados.

A resposta apropriada depende da prevalência e da sensibilidade da alegação. O revisor pode recalcular o desempenho após remover sobreposições suspeitas, comparar estratos afetados e não afetados, e testar um novo conjunto equivalente. O resultado deve mostrar um intervalo, em vez de comprimir a incerteza em um rótulo binário de contaminado ou limpo. Uma queda material em um resultado que sustenta o preço exige escalonamento.

7. Detectar contaminação semântica e familiaridade com o benchmark

A contaminação pode ir além de cópias exatas. Tutoriais, repositórios de soluções, discussões sobre benchmarks, variantes sintéticas e dados de treinamento gerados por modelos podem codificar a tarefa ou a estrutura das respostas. Os modelos também podem aprender formatação e estratégias específicas do benchmark sem memorizar itens individuais. Buscas semânticas, históricos de repositórios, datas de rastreamento da web e análise de exposição podem ajudar a identificar rotas plausíveis.

A equipe de diligência devida deve comparar o desempenho em itens públicos legados com itens recém-criados, sequestrados e estruturalmente equivalentes. Uma grande lacuna pode indicar exposição, mudança de distribuição, diferenças na construção do teste ou vários efeitos combinados. Trata-se de evidência que exige investigação, e não de prova de uma causa específica. Administração cega e controles de acesso rigorosos fortalecem a inferência.

A familiaridade com o benchmark também afeta sistemas agênticos. Ferramentas, prompts ou lógica de roteamento podem conter nomes de benchmarks, padrões de resposta ou atalhos específicos da tarefa. O congelamento do sistema deve, portanto, incluir o código do orquestrador e as bibliotecas de prompts. Um modelo base com desempenho modesto pode parecer forte quando um harness construído manualmente é adaptado ao teste. Esse harness ainda pode ser valioso, mas sua transferência para os fluxos de trabalho dos clientes deve ser demonstrada.

Evidências mais fortes combinam correspondência de artefatos, análise temporal e avaliação sequestrada recente.

Tabela 2. Matriz de testes de vazamento

Os resultados devem ser interpretados considerando o momento, o acesso e o desenho do benchmark.

8. Testar a seleção de benchmarks e alternativas omitidas

O viés de seleção pode surgir antes de qualquer execução. Um alvo pode relatar benchmarks nos quais tem bom desempenho, escolher subtarefas favoráveis ou omitir alternativas respeitadas. A equipe de diligência devida deve reconstruir o universo de benchmarks candidatos a partir de alegações do produto, requisitos de clientes, expectativas regulatórias, práticas acadêmicas e divulgações de concorrentes. A administração deve explicar os critérios de inclusão e exclusão.

A relevância importa mais do que o volume. Executar dezenas de rankings públicos pode criar uma falsa sensação de cobertura, deixando o uso comercial do comprador sem teste. A equipe deve mapear cada benchmark selecionado para a população pretendida, o custo do erro e a decisão. Também deve examinar resultados gerados internamente e não publicados, porque experimentos abandonados ou desfavoráveis podem revelar efeitos de seleção.

Um portfólio de benchmarks pode incluir testes públicos de comparabilidade, testes privados semelhantes aos de clientes, testes de estresse, testes econômicos e testes de segurança. Os pesos devem refletir a exposição da transação e permanecer fixos antes que os resultados sejam conhecidos. Se o vendedor escolher um portfólio diferente, o comprador deve preservar ambas as visões e conciliar a diferença.

9. Reproduzir o cálculo da métrica a partir das saídas brutas

A pontuação reportada deve ser recalculada a partir das previsões brutas, dos rótulos e do código da métrica. Os revisores devem testar denominadores, cálculo de médias, pesos de classe, empates, abstenções, tempos limite, saídas inválidas e registros duplicados. Médias macro e micro podem contar histórias diferentes. A acurácia pode obscurecer o desequilíbrio entre classes. Uma pontuação composta pode ocultar uma falha material em uma dimensão.

A incerteza deve estar ao lado da estimativa pontual. Tamanho da amostra, dependência, execuções repetidas, variação entre anotadores e geração estocástica afetam a precisão. O trabalho do NIST sobre modelos estatísticos para avaliações automatizadas de benchmark enfatiza a necessidade de definir o alvo da medição e as premissas que sustentam as conclusões. O relatório de diligência devida deve informar intervalos de confiança ou outras medidas de incerteza adequadas e evitar precisão falsa.

As métricas devem se conectar às consequências. Uma melhoria de um ponto pode ter pouco valor para o cliente, enquanto uma pequena deterioração em uma classe de erro de alto custo pode importar muito. Os limites devem ser justificados por contratos, economia do fluxo de trabalho, apetite a risco e necessidades dos usuários. Uma posição em ranking isolada raramente estabelece significância econômica.

10. Recriar prompts, ferramentas e intervenção humana

Sistemas generativos e agênticos podem ser altamente sensíveis a prompts, acesso a ferramentas, recuperação, amostragem e instruções do avaliador. O protocolo declarado deve preservar prompts de sistema e de usuário, exemplos few-shot, esquemas de ferramentas, lógica de nova tentativa, temperatura, sementes quando suportadas, limites de contexto e condições de parada. Edições manuais não documentadas ou respostas geradas escolhidas a dedo devem ser tratadas como intervenções.

A assistência humana deve ser visível. Funcionários podem selecionar entradas, corrigir saídas, escolher entre candidatos, rotular respostas limítrofes ou anular falhas. O trabalho humano pode ser uma parte intencional de um serviço valioso. Seu tempo, habilidade, custo, consistência e escalabilidade devem entrar no benchmark e no modelo comercial. Um produto descrito como automatizado não deve ser tratado economicamente como automatizado quando sua qualidade demonstrada depende de trabalho especializado não registrado.

O plano de reprodução deve executar primeiro a configuração divulgada. As sensibilidades podem então variar prompts e controles para testar a robustez. Um método que só tem sucesso sob uma instrução finamente ajustada pode ser apropriado para um fluxo de trabalho estável, embora ofereça evidência mais fraca para capacidade geral.

11. Controlar hardware, concorrência e otimização do sistema

As alegações de latência, vazão e custo dependem de hardware, precisão, tamanho do lote, comprimento da sequência, cache, rede, região, concorrência e utilização. Um alvo pode produzir um resultado laboratorial impressionante em aceleradores escassos com baixa carga, enquanto a previsão assume infraestrutura padronizada de mercado e tráfego sustentado. O ambiente de diligência devida deve capturar telemetria de hardware e do sistema junto com a qualidade.

Inicializações a quente e a frio, acertos de cache, novas tentativas e solicitações com falha exigem relatório separado. A latência percentílica é geralmente mais informativa do que a média para compromissos de serviço. A vazão deve incluir contrapressão e enfileiramento. O custo por tarefa bem-sucedida deve incorporar inferência, recuperação, ferramentas, armazenamento, observabilidade, revisão humana e infraestrutura alocada, e não apenas o custo por token.

A otimização pode ser proprietária e durável. Quantização, compilação, roteamento e agendamento podem criar vantagem genuína. O comprador deve testar se a otimização é transferida com os ativos adquiridos, depende de uma licença de terceiros ou exige especialistas que podem não permanecer. A alegação de benchmark e a viabilidade de entrega da transação devem, portanto, estar conectadas.

12. Executar um protocolo de reprodução pré-registrado

O protocolo deve ser aprovado formalmente antes que a equipe independente veja os resultados finais. Ele declara o sistema alegado, a população de teste, a amostra, as métricas, o método estatístico, o ambiente, as intervenções permitidas, as regras de exceção e os limiares de decisão. Identifica quem pode acessar rótulos, quem executa as rodadas e quem aprova desvios. O pré-registro reduz alterações retroativas e sustenta uma trilha de auditoria defensável.

A execução pode prosseguir por entrada, verificações de integridade, execução de teste, execução bloqueada, recálculo independente, análise de sensibilidade e revisão de exceções. A execução de teste valida a infraestrutura em itens não pontuados. A execução bloqueada usa artefatos controlados e produz registros imutáveis. Qualquer nova execução deve reter a saída original e uma justificativa.

A equipe deve distinguir reprodutibilidade de replicação. A reprodução pode significar obter o resultado com os artefatos e o método do vendedor. A replicação pode testar a alegação subjacente com dados ou métodos construídos de forma independente. Um programa de diligência robusto pode precisar de ambos, especialmente quando o benchmark público está exposto ou a população comercial difere.

As regras de decisão e as alterações permitidas são fixadas antes da execução pontuada.

Tabela 3. Etapas do protocolo de reprodução

Cada etapa de aprovação produz evidências para a próxima decisão de transação.

13. Use avaliação cega e em ambiente isolado quando a exposição for relevante

Testes cegos restringem o acesso da parte avaliada a rótulos, saídas esperadas ou itens finais. Testes em ambiente isolado mantêm os dados em um ambiente controlado e podem impedir sua inclusão em treinamentos futuros. O programa AI Technology Evaluation do NIST usa dados cegos e um ambiente isolado para reduzir o risco de contaminação e melhorar a comparabilidade. Equipes de transação podem adaptar o princípio a alegações materiais.

O vendedor pode fornecer um contêiner ou endpoint controlado enquanto uma equipe independente mantém o conjunto de testes. As entradas devem refletir a população acordada, e o processo deve capturar saídas, recusas, erros, tempos e uso de recursos. Controles de segurança devem impedir a exfiltração de dados por meio de logs, ferramentas ou atualizações de modelo. O protocolo também deve impedir o vazamento de informações do avaliador por meio de feedback informal durante a execução.

Dados novos não criam automaticamente um teste justo. A qualidade, a dificuldade e a rotulagem dos itens exigem revisão. Quando possível, um subconjunto de calibração pode ser examinado em conjunto antes de o conjunto pontuado ser bloqueado. As disputas devem seguir um processo de adjudicação predefinido que preserve decisões cegas e evite a rerrotulagem seletiva.

14. Teste a robustez em condições operacionais relevantes

Uma única pontuação descreve um ponto em um espaço operacional maior. Os testes de robustez variam idioma, geografia, especialização do usuário, qualidade da entrada, extensão do documento, prevalência de classe, comportamento adversarial, pressão de tempo, falha de ferramenta e carga do sistema. As variações devem refletir a exposição a clientes e regulatória, e não perturbações arbitrárias.

A equipe deve distinguir degradação graciosa de efeitos de queda abrupta. Um modelo pode apresentar queda modesta à medida que os documentos ficam mais ruidosos e, depois, falhar abruptamente além de um limiar de contexto ou de recuperação. Um fluxo de trabalho pode permanecer preciso enquanto latência e custo violam os níveis de serviço. Esses pontos de transição podem orientar o planejamento de capacidade, os termos contratuais e o roteiro de integração.

As alegações de robustez precisam incluir incerteza e cobertura. Testar todas as condições é impossível. O relatório deve indicar a região amostrada, as combinações não testadas e o monitoramento necessário após o fechamento. O comprador pode proteger o valor por meio de implantação faseada, retenções, compromissos de suporte ou contraprestação contingente quando condições materiais permanecerem não testadas.

15. Comparar com alternativas credíveis

A diferenciação exige um comparador que o comprador ou cliente realmente possa usar. Isso pode incluir um produto atual, modelo aberto, API comercial, fornecedor especializado, fluxo de trabalho humano ou método estatístico mais simples. O comparador deve receber otimização razoável e os mesmos dados, métrica, limite de hardware e requisito de serviço. Uma linha de base deliberadamente fraca superestima a vantagem.

O teste também deve separar o valor do modelo do valor do sistema. Um alvo pode gerar resultados superiores por meio de dados proprietários, integração de fluxo de trabalho, ciclos de feedback, distribuição ou operações especializadas, mesmo quando o modelo subjacente é substituível. Por outro lado, uma pontuação de modelo líder pode gerar valor de negócio limitado se o produto carecer de direitos sobre dados, adoção por clientes ou economia unitária.

A disponibilidade de comparadores pode mudar rapidamente. O caso da transação deve incluir gatilhos de atualização entre a assinatura e o fechamento e após o fechamento. Uma melhoria material em uma alternativa acessível pode alterar o preço projetado, os requisitos de capital ou o valor da tecnologia proprietária. O acordo e o processo de aprovação devem definir como essas mudanças são avaliadas.

16. Conciliar significância estatística com significância econômica

Um resultado estatisticamente distinguível pode ser economicamente imaterial, e um risco economicamente sério pode permanecer estatisticamente incerto em uma amostra pequena. A equipe de diligência devida deve definir o menor efeito que altera o valor para o cliente, o custo, a segurança, o desempenho contratual ou a avaliação. O desenho da amostra deve buscar resolver esse efeito quando viável.

A análise de decisão pode combinar estimativas de efeito, incerteza e consequência. Erros de alto volume e baixo custo podem ser gerenciados por meio de operações, enquanto falhas graves raras podem exigir testes de estresse e controles direcionados. A equipe deve evitar converter todas as dimensões em uma única pontuação opaca. Qualidade, segurança, latência, custo e esforço humano devem permanecer visíveis antes de qualquer ponderação.

Quando as evidências permanecerem fracas, o tratamento da transação pode refletir a incerteza diretamente. Faixas de preço, earn-outs, garantias, covenants, investimento faseado e condições de fechamento podem alocar risco de forma mais transparente do que um ajuste de probabilidade sem suporte. O conselho deve ver como o mecanismo selecionado responde à lacuna de evidências observada.

17. Estabelecer a ponte entre a qualidade de laboratório e o desempenho em produção

A produção introduz mix de tráfego, entradas imperfeitas, adaptação do usuário, deriva de recuperação, indisponibilidades de ferramentas, controles de segurança, monitoramento, escalonamento humano e modelos em mudança. A equipe de diligência devida deve criar uma ponte da qualidade de benchmark para o sucesso da tarefa de ponta a ponta. Cada etapa deve identificar a evidência, a perda, o custo e o responsável.

Os testes sombra podem reproduzir ou espelhar casos representativos de produção sem permitir que o sistema candidato controle o resultado real. Um piloto limitado pode testar o fluxo de trabalho ao vivo e o comportamento do usuário sob salvaguardas acordadas. Backtests históricos podem adicionar escala, embora possam deixar de capturar distribuições em mudança e efeitos de feedback. As evidências mais fortes geralmente combinam métodos.

A ponte deve conciliar métricas no nível do modelo com medidas de cliente e financeiras: tarefas bem-sucedidas, tempo de ciclo, retrabalho, escalonamento, retenção, preço, créditos de serviço, computação e mão de obra. Um modelo pode melhorar a precisão enquanto reduz a margem bruta por meio de inferência ou revisão caras. Uma pontuação principal mais baixa pode gerar mais valor quando é confiável, rápida e econômica no fluxo de trabalho alvo.

A qualidade do benchmark reportado é reduzida por efeitos de distribuição, fluxo de trabalho e operacionais antes de atingir os resultados de cliente e de caixa.

Tabela 4. Ponte de evidências da lacuna de produção

Cada camada converte o desempenho técnico em uma consequência operacional e financeira.

18. Reconstruir a economia de inferência e suporte

A economia unitária deve ser medida por resultado bem-sucedido do cliente. A pilha de custos pode incluir chamadas de modelo, tempo de acelerador, recuperação, armazenamento, rede, ferramentas de terceiros, observabilidade, segurança, novas tentativas, revisão humana, suporte e custo de plataforma alocado. Mínimos contratuais e capacidade reservada podem gerar custo mesmo quando a utilização é baixa.

A qualidade e o custo interagem. Um modelo menor pode reduzir a despesa de inferência, mas aumentar erros e revisão. Um modelo maior pode melhorar a qualidade de primeira passagem enquanto eleva a latência e a concentração de fornecedores. O roteamento pode criar valor quando envia cada tarefa ao sistema menos custoso que atende ao limite exigido. O benchmark deve, portanto, relatar uma fronteira de qualidade-custo em vez de uma única pontuação em uma única configuração.

As previsões devem usar distribuições observadas e restrições de capacidade. Descontos por volume, preços de hardware e eficiências de modelo podem melhorar, enquanto o mix de clientes, o comprimento do contexto e as expectativas de serviço podem elevar o custo. Os cenários devem preservar ambas as direções. A eficiência futura não verificada deve permanecer como estimativa da administração até ser sustentada por contratos ou engenharia demonstrada.

19. Examine a governança e os incentivos do benchmark

O comprador deve entender quem projetou, executou, revisou e aprovou cada avaliação. Pesquisadores, fundadores, equipes de vendas e assessores podem enfrentar incentivos para apresentar resultados favoráveis. A independência é reforçada por meio de funções separadas, regras pré-registradas, retenção de saídas brutas e revisão por pessoas que não criaram a alegação.

Mudanças após uma execução desfavorável merecem atenção especial. Algumas mudanças corrigem erros genuínos; outras restringem a população, substituem uma métrica ou excluem falhas. O registro deve preservar o resultado original, o motivo, o aprovador e o efeito. Reexecuções repetidas não documentadas ou saídas brutas ausentes enfraquecem a confiança, mesmo quando uma pontuação posterior é plausível.

O conselho deve receber limitações relevantes em linguagem simples. Um anexo técnico não pode compensar uma afirmação de destaque que implique desempenho mais amplo do que as evidências sustentam. A governança também deve definir quem pode fazer declarações públicas, a clientes ou relativas à transação e como essas declarações permanecem alinhadas aos resultados validados.

20. Avalie evidências de benchmark e certificação de terceiros

Avaliações independentes, auditorias e certificações podem reforçar as evidências quando seu escopo, métodos, competência e independência forem adequados à alegação. A equipe de diligência devida deve obter o relatório real, a versão testada, o período, as exclusões e as conclusões. Um logotipo ou certificado pode abranger a gestão de segurança da informação e dizer pouco sobre a qualidade do modelo.

A equipe deve examinar o acesso a evidências brutas, a amostragem, a reprodutibilidade, os conflitos, a linguagem de confiança e se o avaliador testou o produto ou aceitou representações da administração. Normas podem apoiar controles consistentes, mas não estabelecem que uma previsão comercial seja alcançável. A asseguração deve ser mapeada para a alegação da transação em vez de tratada como um selo genérico.

Quando o alvo depende de um organizador de benchmark, o comprador deve revisar regras, limites de submissão, sigilo dos testes, divulgação de hardware e mecanismos de auditoria. A MLCommons e outros organismos de benchmark publicam regras para programas específicos. A versão e a categoria aplicáveis são importantes. O relatório de diligência devida deve evitar combinar pontuações geradas sob regras diferentes.

21. Avalie a relevância regulatória e contratual

As obrigações de avaliação de AI variam conforme a função, a jurisdição e o uso. A orientação da Comissão Europeia sobre AI de uso geral explica as expectativas de documentação e avaliação no âmbito do AI Act, incluindo deveres adicionais para modelos com risco sistêmico. A orientação do governo do Reino Unido descreve a asseguração de AI como um conjunto de mecanismos que apoiam a avaliação e a comunicação de riscos. Reguladores setoriais e contratos com clientes podem impor requisitos adicionais.

A equipe da transação deve mapear as funções de fornecedor, implantador, importador e distribuidor; os usos pretendidos; a relevância para alto risco ou segurança; e a abrangência geográfica. Os resultados técnicos devem estar vinculados à documentação exigida, ao monitoramento, à resposta a incidentes e à supervisão humana. Assessores jurídicos qualificados devem interpretar a lei aplicável e as datas de aplicação.

Os contratos podem definir testes de aceitação, níveis de serviço, direitos de auditoria, controles de alteração de modelo, restrições de dados, garantias e medidas de reparação. O comprador deve comparar os testes de diligência devida com esses compromissos. Um benchmark que exclui os casos exatos cobertos por uma garantia ao cliente pode criar exposição oculta, mesmo quando a pontuação média é forte.

22. Testar segurança e desempenho adversarial

Um produto AI pode ter bom desempenho em casos comuns e permanecer vulnerável a injeção de prompt, envenenamento de dados, extração de modelo, abuso de ferramentas, saídas inseguras ou negação de serviço. Os testes de segurança devem refletir a arquitetura e o modelo de ameaças. As orientações do Centro Nacional de Segurança Cibernética do Reino Unido para o desenvolvimento seguro de AI e os recursos de gestão de riscos de AI do NIST fornecem âncoras de controle úteis.

O ambiente de benchmark deve preservar os limites do sistema. Um teste de qualidade de modelo em sandbox não estabelece a segurança de recuperação, plugins, agentes, credenciais ou infraestrutura de implantação. Resultados de red team e adversariais devem indicar escopo, acesso, critérios de sucesso, mitigações e risco residual. A demonstração de um ataque não mede toda a exposição.

Consequências da transação podem incluir custo de remediação, atraso na implantação, notificações a clientes, restrições de seguro, violação contratual e envolvimento regulatório. O comprador deve conectar achados materiais ao plano de fechamento, garantias, depósito em garantia, orçamento de investimento e autoridade operacional. As evidências de segurança devem permanecer protegidas e ser compartilhadas com base na necessidade de conhecimento.

23. Inspecionar o código de avaliação como software crítico para a transação

O código de avaliação pode alterar resultados por meio de parsing, correspondência de respostas, tratamento de timeout, randomização, carregamento de dados e agregação. Ele deve receber revisão de código, testes e controle de versão comparáveis aos de outros cálculos críticos para a transação. O revisor deve executar casos positivos e negativos conhecidos no avaliador e confirmar que as falhas são representadas corretamente.

Dependências podem introduzir deriva. Uma atualização de biblioteca pode alterar tokenização, comportamento numérico ou parâmetros padrão. O manifesto do ambiente deve incluir versões de pacotes e detalhes da plataforma. Sementes melhoram a rastreabilidade onde os sistemas oferecem suporte a determinismo, embora execuções repetidas ainda possam ser necessárias para saídas estocásticas.

Código de avaliação gerado pode acelerar a criação de testes, mas deve ser inspecionado e validado. A assistência de máquina pode detectar itens duplicados, rótulos inconsistentes e padrões de pontuação anômalos. Ela não pode estabelecer que uma métrica representa valor para o cliente. A responsabilidade metodológica permanece com revisores qualificados.

24. Conciliar evidências de clientes com evidências de benchmark

Uso por clientes, renovações, reclamações e resultados realizados fornecem uma camada de evidência diferente. A equipe deve comparar estratos de benchmark com coortes de clientes, fluxos de trabalho e registros de suporte. Forte retenção de clientes pode validar o valor do produto apesar de uma pontuação pública modesta. Um benchmark líder pode coexistir com adoção limitada ou trabalho intensivo de serviços.

Referências e estudos de caso exigem verificação. O comprador deve inspecionar contratos, faturas, registros de uso e medidas de resultado acordadas, conforme as permissões. Entrevistas com clientes devem distinguir a capacidade do produto do envolvimento do fundador, engenharia personalizada e concessões de preço. Uso concentrado por poucos clientes sofisticados pode não ser transferível para um mercado mais amplo.

A ponte deve identificar qual métrica de benchmark prevê renovação, expansão, preço ou custo. Correlação em uma pequena amostra histórica é evidência limitada. A previsão deve preservar a incerteza e monitorar a relação após o fechamento. Quando dados de resultados de clientes contradizem o benchmark, a equipe deve investigar medição, população e fluxo de trabalho antes de escolher uma das versões.

25. Identificar deriva do benchmark entre a assinatura e o fechamento

Sistemas AI, concorrentes e benchmarks públicos podem mudar durante uma transação. A empresa-alvo pode lançar um novo modelo, trocar um fornecedor terceirizado ou alterar o stack de produtos. Um conjunto de testes público pode ficar mais exposto. O acordo deve definir alterações permitidas no curso ordinário, notificação, preservação de evidências e gatilhos de reteste.

O comprador deve preservar a configuração assinada e monitorar a configuração de produção. Uma pontuação melhor de uma nova versão não elimina risco de transição, licenciamento, custo ou confiabilidade. Uma pontuação menor pode refletir um controle de segurança ou um ponto operacional mais barato que melhora o valor total. Mudanças devem ser avaliadas em termos de qualidade, custo, segurança, conformidade e impacto no cliente.

As condições de fechamento podem concentrar-se em entregáveis, acesso ou remediação específicos, em vez de uma promessa genérica de que a tecnologia permanecerá satisfatória. Materialidade e medidas corretivas exigem redação jurídica. A estrutura de diligência devida fornece as evidências e os limites para esse trabalho.

26. Traduza a lacuna de reprodutibilidade em avaliação

A lacuna de reprodutibilidade é a diferença entre o caso econômico declarado e o caso respaldado por evidências controladas. Ela pode decorrer de menor qualidade, maior custo, implantação mais lenta, uso endereçável mais restrito, remediação adicional ou durabilidade mais fraca. A ponte de avaliação deve identificar cada mecanismo, em vez de aplicar um desconto arbitrário.

A receita pode mudar por meio de conversão, retenção, preço e população elegível de clientes. A margem pode mudar por meio de inferência, revisão, suporte e infraestrutura. As necessidades de capital podem mudar por meio de remediação, aquisição de dados e implantação. O momento afeta o valor presente e o financiamento. As faixas de cenários devem evitar a contagem dupla de uma única lacuna de evidência em várias linhas.

O comprador pode preservar o valor da opção estratégica separadamente do valor respaldado. Uma capacidade promissora pode justificar investimento continuado sem sustentar o mesmo preço de compra que um resultado de produção reproduzido. O conselho deve ver ambas as categorias e os marcos que podem converter o valor da opção em valor respaldado.

27. Alocar risco por meio dos termos da transação

Os termos podem responder a evidências que não podem ser resolvidas antes da assinatura. A contraprestação contingente pode vincular o pagamento a resultados de clientes, de desempenho ou de margem medidos de forma independente. As garantias podem abordar a exatidão dos registros de benchmark divulgados, a completude dos artefatos ou a ausência de intervenção manual não divulgada. Os covenants podem preservar sistemas e exigir acesso para testes.

As métricas para uso contratual precisam de precisão. O contrato deve identificar o sistema, a população, o administrador do teste, o ambiente, o cálculo, a incerteza, as exceções, o controle de alterações e o processo de disputa. Uma classificação em um leaderboard público costuma ser mutável demais para um earn-out. Resultados operacionais, como uso pago, renovação ou lucro bruto, podem ser mais duradouros, embora introduzam outras dependências.

As medidas corretivas devem ser proporcionais e exequíveis. Advogados e consultores fiscais e contábeis devem avaliar o tratamento. A equipe técnica deve fornecer fatos e métodos reproduzíveis, sem redigir além de sua especialidade.

28. Proteger o caso de financiamento

Credores e comitês de crédito podem basear-se em receita, margem, fluxo de caixa e despesas de capital previstos, influenciados por alegações de AI. O modelo de financiamento deve usar o caso respaldado por evidências e testar reprodução atrasada ou malsucedida, perda de clientes, remediação, mudanças de preços de fornecedores e capacidade computacional adicional. A capacidade de endividamento deve permanecer distinguível do potencial estratégico.

Compromissos de informação podem exigir relatórios sobre mudanças materiais no modelo, falhas de serviço, eventos regulatórios e concentração de clientes. Pacotes de garantias e covenants raramente compensam uma tese de produto não comprovada. O comprador deve avaliar a liquidez durante o período necessário para validar e remediar o sistema.

Um benchmark forte pode sustentar a confiança, mas não gera caixa por si só. O caso de crédito deve conciliar os resultados dos testes com receita contratada, recebimentos, margem bruta, capital de giro e investimento. Isso protege tanto a transação quanto a empresa adquirida de um plano operacional que pressupõe conversão imediata do laboratório para o mercado.

29. Exemplo prático: uma aquisição hipotética de workflow AI

Suponha que um comprador hipotético avalie uma empresa de workflow de documentos AI. A administração relata uma pontuação de 92 em um conjunto público de tarefas, latência mediana de dois segundos e margem bruta de 78 por cento. A projeção pressupõe expansão empresarial com base em liderança de qualidade. Esses números são premissas ilustrativas e não descrevem uma empresa ou transação.

O grafo de evidências identifica uma biblioteca de prompts não divulgada, uma divisão de teste modificada e a exclusão de casos que excederam o tempo limite. A reprodução controlada produz uma pontuação ilustrativa de 87. Um conjunto cego novo, representativo de documentos de clientes, produz 81, com desempenho mais fraco em entradas longas e multilíngues. Incluir novas tentativas, revisão humana e inferência alocada reduz a margem bruta ilustrativa para 66 por cento no volume previsto.

O comprador não trata o resultado como um desconto único. Ele reconstrói a receita elegível, a retenção, a capacidade de suporte, a computação e a remediação. Em um cenário ilustrativo, o valor independente respaldado por evidências fica 18 por cento abaixo do caso inicial. As partes poderiam responder por meio de preço, contraprestação contingente vinculada a resultados de produção efetivamente pagos, um covenant de remediação e suporte técnico mantido. O tratamento efetivo dependeria de evidências, negociação e aconselhamento profissional.

O tratamento da transação se fortalece à medida que aumentam a materialidade comercial e a fragilidade das evidências.

Tabela 5. Resposta da transação às evidências de referência

A resposta deve abordar o mecanismo pelo qual a lacuna afeta o valor.

30. Transferir as evidências para o plano de integração

O registro de benchmark deve sobreviver ao fechamento. Os responsáveis pela integração precisam do sistema congelado, das lacunas não resolvidas, das ações de remediação, de conjuntos de testes semelhantes aos de clientes, do modelo de custos, dos limites de monitoramento e da autoridade para mudanças de modelo. Repetir o teste de diligência devida após mudanças cria continuidade entre avaliação e operações.

Os primeiros cem dias podem priorizar lacunas e dependências materiais de evidência. O trabalho pode incluir garantir direitos de dados, reforçar a infraestrutura de avaliação, reduzir a revisão humana, negociar termos com provedores, melhorar o desempenho em contextos longos ou estabelecer a mensuração de resultados para clientes. Cada ação deve estar vinculada ao caso da transação e ao orçamento.

O comprador deve evitar transformar um benchmark de diligência devida em uma meta permanente de produto sem revisão. Mercados, sistemas e necessidades dos clientes mudam. O ativo durável é um processo de avaliação governado que pode atualizar testes preservando a linhagem e o histórico de decisões.

31. Monitorar desvios pós-fechamento sem reescrever a linha de base

O relatório pós-fechamento deve comparar o desempenho real com o caso de evidências assinado. A equipe pode atualizar previsões mantendo o benchmark original, as premissas e o tratamento da transação. Isso evita que um rebase favorável obscureça se a tese de investimento se concretizou.

O monitoramento pode incluir mudança na distribuição de dados, qualidade por coorte, eventos de segurança, latência, custo, revisão humana, resultados para clientes e mudanças de modelo ou de provedor. Os limites devem acionar investigação e decisões com responsabilização. Alarmes estatísticos precisam de interpretação operacional; pequenas flutuações podem ser ruído, enquanto médias estáveis podem ocultar a deterioração de coortes.

As diferenças observadas devem aprimorar a diligência devida futura. O comprador pode registrar quais testes pré-assinatura previram o desempenho em produção, quais lacunas importaram financeiramente e quais controles reduziram a incerteza. Informações sensíveis devem permanecer governadas e anonimizadas quando apropriado.

32. Adaptar o método a setores regulados e de altas consequências

Serviços financeiros, saúde, energia, infraestrutura e uso do setor público podem exigir populações específicas do setor, custos de erro, explicabilidade, supervisão humana, resiliência e documentação. Um benchmark geral deve ser complementado com testes que reflitam as decisões e os usuários aplicáveis. Especialistas qualificados devem definir os requisitos regulatórios e profissionais.

Em crédito ou seguros, a prevalência de classe, a equidade, os resultados adversos e a mudança de modelo podem importar. Na saúde, relevância clínica, variação entre locais e fatores humanos podem predominar. Em sistemas industriais, desvio de sensores, condições ambientais e fallback seguro podem importar mais do que uma pontuação pública de acurácia. Em fluxos de trabalho jurídicos ou de conformidade, a validade das citações, a confidencialidade e a carga de revisão podem determinar o valor.

O quadro comum permanece: identificar a alegação, preservar artefatos, definir a população, reproduzir o resultado, testar condições de produção e conectar evidências ao tratamento da transação. A adaptação setorial altera os testes e as consequências, não a necessidade de rastreabilidade.

33. Proteger a confidencialidade, a privacidade e a propriedade intelectual

A diligência devida de benchmark pode expor pesos de modelo, código, dados de clientes, segredos comerciais e informações de segurança. O protocolo de equipe limpa deve definir usuários permitidos, ambientes, transferências, resultados, retenção e destruição. Dados sintéticos ou desidentificados podem reduzir a exposição, embora possam alterar a população e devam ser validados.

A empresa-alvo deve demonstrar direitos sobre conjuntos de dados, rótulos, conteúdo de benchmark e ferramentas de avaliação. Licenças abertas podem conter condições de atribuição, redistribuição ou uso. Contratos com clientes podem restringir testes secundários ou transferência em caso de mudança de controle. O assessor jurídico deve avaliar os direitos e recursos específicos.

O comprador também deve proteger seu próprio desenho de teste e seus limites estratégicos. A divulgação de um conjunto segregado pode destruir valor futuro. Execução controlada, registros de auditoria e acesso compartimentado ajudam a preservar a integridade sem impedir a revisão adequada pelo vendedor e a resolução de disputas.

34. Governar a assistência por máquina no processo de diligência devida

A assistência por máquina pode inventariar artefatos, comparar versões, detectar possíveis sobreposições, agrupar erros, gerar variações de teste, executar harnesses e preparar análises de sensibilidade. Cada resultado deve manter links de origem, versões de código e decisões do revisor. A automação é mais útil quando melhora a cobertura e a rastreabilidade.

O próprio sistema de diligência devida pode introduzir erro. Itens de teste gerados podem ser ambíguos, rótulos sintéticos podem estar errados, a correspondência semântica pode superestimar a contaminação e a pontuação automatizada pode interpretar mal resultados válidos. São necessários conjuntos de validação, revisão humana e registros de exceções. Decisões materiais não devem depender de um agregado opaco produzido por uma ferramenta não testada.

Controles de acesso e confidencialidade aplicam-se aos modelos de assistência. Enviar código da empresa-alvo ou registros de clientes a um serviço externo pode violar obrigações. A equipe deve usar ambientes aprovados e registrar provedores, configurações de retenção e fluxos de dados. Revisores de segurança e jurídicos devem aprovar usos sensíveis.

35. Estruturar o pacote de decisão do conselho em torno das lacunas de evidência

O pacote do conselho deve mostrar o resultado alegado, o resultado reproduzido, a ponte para produção, a incerteza, o vínculo comercial e as limitações não resolvidas. Deve identificar quanto da receita projetada, da margem e do valor depende de cada alegação material. Um mapa de calor conciso pode vincular a fragilidade da evidência e a exposição financeira à decisão proposta.

As perguntas devem incluir se o sistema testado é transferível, se os dados representam o uso contratado, se a contaminação foi delimitada, se alternativas foram testadas, se a economia unitária inclui todo o trabalho e se o caso de financiamento sobrevive a um cenário adverso. As respostas devem remeter a artefatos preservados, e não a garantias sem suporte.

A aprovação deve declarar quais alegações sustentam o preço, quais permanecem opcionais, quais termos alocam risco, o que deve ocorrer antes do fechamento e quem é responsável pela validação pós-fechamento. Novas informações devem acionar nova aprovação quando ultrapassarem limites acordados.

36. Operar um protocolo repetível de diligência devida de benchmark

Um protocolo repetível tem seis etapas: entrada de alegações, grafo de evidências, congelamento de artefatos, testes pré-registrados, ponte comercial e decisão de transação. Cada etapa tem um responsável, um prazo-limite de evidências, um processo de exceção e um resultado. A equipe de transação pode dimensionar a profundidade conforme a materialidade, preservando a mesma estrutura de controles.

As medidas de processo podem incluir afirmações rastreadas até evidências brutas, artefatos ausentes na entrada, constatações de vazamento, diferenças de pontuação reproduzida, fatores que explicam lacunas de produção, exceções após o congelamento, tempo decorrido e alterações nas premissas de valor. Essas medidas indicam a qualidade e a carga de trabalho da diligência. Elas não provam que um teste causou um resultado da transação.

A adoção pode começar com as poucas afirmações que geram a maior parte do valor. Um comprador pode congelar o sistema objeto da alegação, reproduzir um teste material, executar um conjunto cego representativo e reconstruir a economia unitária antes de investir em uma plataforma ampla. A capacidade institucional cresce por meio de protocolos preservados, suítes de testes, revisores e feedback pós-fechamento. O resultado é um caminho mais rápido da asserção técnica para uma decisão de preço, contrato e integração com responsabilização.

O protocolo também deve definir uma regra de parada. Testes adicionais têm valor quando podem alterar preço, alocação de risco, financiamento, prontidão para fechamento ou orçamento de integração. O teste pode ser encerrado quando a decisão material for sustentada dentro da incerteza acordada, ou quando a incerteza remanescente for alocada de forma mais eficiente por meio de termos e controles pós-fechamento. O responsável pela diligência deve documentar esse julgamento, as evidências ainda ausentes e a pessoa que aceita a exposição residual. Isso evita que trabalho técnico sem escopo definido atrase uma transação sem melhorar a decisão.

A repetibilidade também depende de manter uma biblioteca de benchmarks controlada. Os conjuntos de teste devem conter responsáveis, usos pretendidos, classificações de acesso, histórico de exposição, datas de atualização e regras de descontinuação. Itens públicos podem continuar úteis para comparabilidade, enquanto conjuntos novos e semelhantes aos de clientes fornecem evidências mais fortes para transferência. A biblioteca deve registrar quais sistemas foram expostos a cada item, para que equipes futuras não confundam um teste exposto com um teste cego. Essa disciplina operacional protege o valor dos ativos de avaliação ao longo das transações.

Conclusão

A diligência de benchmark AI deve tratar uma pontuação relatada como o início de um processo de evidências. Uma afirmação pronta para decisão conecta um sistema identificado, população apropriada, protocolo controlado, métrica recalculável e incerteza a uma premissa comercial. Vazamento, seleção, condições de execução e economia de produção devem permanecer visíveis.

A reprodução controlada pode estabelecer se o resultado relatado sobrevive ao método divulgado. Testes cegos novos e avaliação semelhante à de produção podem estabelecer evidências mais fortes para generalização e valor para o cliente. Nenhum dos dois elimina a incerteza além das condições amostradas. O conselho deve ver a lacuna remanescente e o mecanismo pelo qual ela afeta receita, margem, capital, prazo e risco.

Um grafo de evidências de benchmark, protocolo pré-registrado e ponte para produção dão às equipes de transação um método repetível. Eles também permitem que as partes aloquem risco não resolvido por meio de preço, valor contingente, garantias, condições, financiamento e ações de integração. A assistência automatizada pode melhorar a cobertura e a velocidade dentro desse processo governado.

O objetivo é um caso de aquisição que possa ser reconstruído da afirmação ao caixa. Essa disciplina sustenta uma avaliação, financiamento e responsabilização pós-fechamento mais críveis em transações nas quais o desempenho de AI é parte material do valor.

Referências

1. National Institute of Standards and Technology. Estrutura de Gerenciamento de Riscos AI. https://www.nist.gov/itl/ai-risk-management-framework
2. Instituto Nacional de Padrões e Tecnologia. Estrutura de Gestão de Riscos de Inteligência Artificial: Perfil de Inteligência Artificial Generativa, NIST AI 600-1. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
3. Manual do RMF de AI. https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook
4. Instituto Nacional de Padrões e Tecnologia. Visão geral da avaliação de tecnologia AI. https://pages.nist.gov/ai-technology-evaluation/
5. Instituto Nacional de Padrões e Tecnologia. Rumo a melhores práticas para avaliações automatizadas de benchmark. https://www.nist.gov/news-events/news/2026/01/towards-best-practices-automated-benchmark-evaluations
6. Instituto Nacional de Padrões e Tecnologia. Ampliando a caixa de ferramentas de avaliação de AI com modelos estatísticos, NIST AI 800-3. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.800-3.pdf
7. Instituto Nacional de Padrões e Tecnologia. Avaliação de riscos e impactos de AI, documento complementar do Programa ARIA. https://ai-challenges.nist.gov/aria/docs/ARIA_Program_Companion_Document_Dec20.pdf
8. Governo do Reino Unido. Introdução à garantia de AI. https://www.gov.uk/government/publications/introduction-to-ai-assurance/introduction-to-ai-assurance
9. Governo do Reino Unido. Portfólio de técnicas de garantia de AI. https://www.gov.uk/guidance/portfolio-of-ai-assurance-techniques
10. Governo do Reino Unido. Kit de ferramentas para AI responsável. https://www.gov.uk/government/collections/responsible-ai-toolkit
11. Centro Nacional de Segurança Cibernética do Reino Unido. Diretrizes para o desenvolvimento seguro de sistemas de AI. https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development
12. Comissão Europeia. Obrigações para AI de uso geral previstas na Lei de AI. https://digital-strategy.ec.europa.eu/en/factpages/general-purpose-ai-obligations-under-ai-act
13. Comissão Europeia. Diretrizes sobre obrigações para fornecedores de AI de uso geral. https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers
14. Comissão Europeia. Diretrizes sobre o escopo das obrigações para fornecedores de modelos de AI de uso geral. https://digital-strategy.ec.europa.eu/en/library/guidelines-scope-obligations-providers-general-purpose-ai-models-under-ai-act
15. Comissão Europeia. Código de Práticas para AI de Uso Geral. https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai
16. União Europeia. Regulamento (UE) 2024/1689 que estabelece regras harmonizadas sobre inteligência artificial. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
17. Banco Central dos UAE. Nota de Orientação sobre Proteção do Consumidor e Adoção e Uso Responsáveis de Inteligência Artificial. https://rulebook.centralbank.ae/en/rulebook/guidance-note-consumer-protection-and-responsible-adoption-and-use-artificial-intelligence
18. Organização para a Cooperação e Desenvolvimento Econômico. Princípios da OCDE AI. https://oecd.ai/en/ai-principles
19. Organização Internacional de Normalização. ISO/IEC 42001 Sistema de gestão de inteligência artificial. https://www.iso.org/standard/81230.html
20. Organização Internacional de Normalização. ISO/IEC 23894 Orientações sobre gestão de riscos para inteligência artificial. https://www.iso.org/standard/77304.html
21. MLCommons. Políticas e resultados do MLPerf. https://mlcommons.org/benchmarks/
22. Autoridade da Concorrência e dos Mercados. Diretrizes de avaliação de fusões. https://www.gov.uk/government/publications/merger-assessment-guidelines
23. Departamento de Justiça dos EUA e Comissão Federal de Comércio. Diretrizes de Fusões de 2023. https://www.justice.gov/atr/2023-merger-guidelines
24. Fundação IFRS. IFRS 3 Combinações de Negócios. https://www.ifrs.org/issued-standards/list-of-standards/ifrs-3-business-combinations/
25. Public Company Accounting Oversight Board. AS 2501: Auditoria de estimativas contábeis, incluindo mensurações de valor justo. https://pcaobus.org/oversight/standards/auditing-standards/details/AS2501