Diligência de Capital de Crescimento Nativa de AI: Velocidade de Funcionalidades, Retenção e Dependência de Modelo

1. Defina a decisão de investimento

A diligência de growth equity deve começar pela decisão que o comitê de investimentos precisa tomar. O mandato deve especificar o título proposto, os recursos captados, a participação, os direitos de governança, o período de detenção esperado, o framework de retorno e as condições materiais. Uma instrução ampla para avaliar uma empresa AI pode gerar atividade extensa sem resolver as questões de preço, estrutura e risco que regem a alocação de capital.

O quadro de decisão deve identificar a tese operacional. A administração pode argumentar que lançamentos rápidos de produto aumentam a adoção, que a adoção produz resultados recorrentes para o cliente, que esses resultados sustentam retenção e expansão e que escala melhora a margem de contribuição. Cada elo exige uma definição, uma fonte e um período de observação. Um resultado forte em um elo não prova o restante da cadeia.

O comitê deve aprovar o padrão de evidências antes que a diligência acelere. O padrão deve distinguir registros verificados, declarações da administração, cálculos testados, evidências de terceiros e cenários hipotéticos. Informações materiais ausentes devem permanecer visíveis. O investidor também deve decidir quais constatações podem alterar a avaliação, os termos do título, a governança, o financiamento escalonado, as condições ou a decisão de interromper.

2. Construa a arquitetura integrada de diligência

As frentes de trabalho comercial, de produto, técnica, financeira e de governança devem usar um único registro de alegações. Relatórios separados podem descrever o mesmo fato de formas diferentes, aplicar períodos inconsistentes ou deixar passar uma dependência que atravessa funções. A arquitetura integrada atribui cada alegação material a um responsável, fonte, teste, revisor e consequência de investimento.

A arquitetura deve abranger a finalidade do produto, os segmentos de clientes, o histórico de lançamentos, o sucesso das tarefas, a adoção, a retenção, a precificação, o reconhecimento de receita, a alocação de custos, as dependências de modelos e de nuvem, os direitos sobre dados, a segurança, a regulação, a organização, a previsão, a necessidade de capital e a tabela de capitalização. Também deve preservar a relação entre esses elementos. Uma nova funcionalidade pode melhorar a adoção ao mesmo tempo que aumenta o custo de inferência, o trabalho de implementação ou a concentração de modelos.

A estrutura de gestão de riscos AI do NIST conecta práticas organizacionais com mapeamento, medição, gestão e governança ao longo do ciclo de vida AI [1]. Seu núcleo exige teste, avaliação, verificação e validação documentados, e monitoramento em produção sob condições semelhantes às de implantação [2]. Esses princípios sustentam um sistema de evidências de investimento, embora o investidor deva adaptá-los à transação e à empresa.

Cada etapa exige uma população, fonte, período e revisão definidos antes de sustentar a próxima conclusão.

3. Criar o registro de evidências

O registro de evidências é o registro da transação para alegações relevantes. Cada entrada deve indicar a afirmação, a definição da métrica, a população, o período, o sistema de origem, o método de extração, o cálculo, o responsável, o revisor, a versão, a limitação e a potencial resposta de investimento. O registro deve vincular-se aos arquivos de origem, mantendo controles de acesso e confidencialidade.

Os painéis de gestão são pontos de partida úteis. Eles podem alterar definições, excluir atividades malsucedidas, combinar tráfego de produção e de teste ou relatar uma visão instantânea atual ao lado de uma previsão histórica. A equipe de diligência devida deve conciliar as métricas selecionadas com os sistemas de origem, contratos e registros contábeis. A reexecução deve concentrar-se nas alegações que impulsionam a avaliação, a proteção contra queda ou a necessidade de capital.

O registro de evidências deve reter evidências adversas. Avaliações que falharam, coortes com churn, estouros de custos, reclamações de clientes e direitos pendentes podem explicar a variedade de resultados de forma mais eficaz do que uma data room impecável. Uma exceção deve ter um responsável, relevância financeira, ação proposta e data de decisão. Excluí-la após uma solução alternativa elimina a trilha de auditoria.

Tabela 1. Campos centrais do registro de evidências

Um campo preenchido exige evidência da fonte e revisão proporcional à sua importância para o investimento.

4. Definir o escopo do produto nativo de AI

A equipe de diligência devida deve estabelecer o que torna a empresa nativa de AI em termos operacionais. O produto pode treinar modelos proprietários, ajustar modelos de terceiros, orquestrar vários modelos, aplicar lógica de recuperação e de fluxo de trabalho, fornecer infraestrutura ou incorporar serviços externos de AI em uma aplicação mais ampla. Essas arquiteturas criam diferentes exposições de propriedade intelectual, custo, confiabilidade e troca de fornecedor.

O mapa do produto deve identificar cada fluxo de trabalho voltado ao cliente, o caminho do modelo e dos dados, a intervenção humana, o ambiente de produção e a promessa comercial. Uma única empresa pode conter várias arquiteturas. Um fluxo de trabalho pode usar um classificador proprietário, outro pode encaminhar para um provedor de modelos de base, e um terceiro pode exigir revisão especializada. A margem e a confiabilidade agregadas podem ocultar essas diferenças.

O escopo também afeta a comparabilidade. Uma empresa cuja economia depende de inferência de terceiros não deve ser avaliada apenas como software tradicional. Uma implantação com forte componente de serviços não deve ser apresentada como receita recorrente de autoatendimento sem evidência. O investidor deve usar o modelo operacional real, os direitos contratuais e os direcionadores de custo, e não um rótulo.

5. Definir um lançamento controlado

A velocidade de funcionalidades exige uma unidade estável de análise. Uma versão deve representar uma mudança em produção que chega a uma população elegível de clientes e pode ser associada a comportamento ou resultados definidos. Commits de código, experimentos, demonstrações internas e anúncios de marketing são eventos separados. Contá-los em conjunto recompensa atividade sem testar o valor para o cliente.

O registro da versão deve incluir usuário pretendido, problema, responsável, aprovação, data de implantação, população elegível, lógica de exposição, plano de rollback, resultado da avaliação, histórico de incidentes e hipótese comercial. Mudanças relevantes de modelo, prompt, recuperação, dados e políticas devem ser incluídas porque podem alterar o comportamento do produto sem uma mudança visível na interface.

A velocidade deve ser avaliada ao lado da qualidade e da reversibilidade. Versões frequentes podem demonstrar capacidade de aprendizado quando telemetria, testes e rollback são robustos. Também podem criar fragmentação, carga de suporte e risco de confiabilidade. O investidor deve medir a proporção de versões que chegam à produção estável, atingem seu limite de aceitação e permanecem com suporte após a janela de observação.

6. Meça a velocidade de funcionalidades

Medidas úteis de velocidade incluem lead time desde o problema aprovado até a produção, frequência de implantação, aceitação de versões, taxa de rollback, escape de defeitos, cobertura de avaliação e tempo de remediação. O denominador deve ser explícito. O lead time mediano para versões aceitas pode comunicar mais do que uma média distorcida por algumas iniciativas abandonadas.

A equipe deve segmentar a velocidade por área de produto, tipo de cliente e classe de mudança. Um ajuste de interface do usuário, uma migração de modelo e um fluxo de trabalho regulamentado exigem testes e tolerâncias ao risco diferentes. Comparações entre períodos devem explicar mudanças no tamanho da equipe, na arquitetura, no mix de clientes e na política de versões.

A velocidade pode ser comparada ao plano de investimento. Se o crescimento exigir uma sequência definida de controles corporativos, integrações ou capacidades de fluxo de trabalho, a diligência devida deve testar se a vazão histórica sustenta essa sequência. A previsão deve incluir descoberta, revisão de segurança, aceitação do cliente e esforço de implantação. Estimativas de engenharia por si só não estabelecem disponibilidade comercial.

7. Conecte versões a coortes de adoção

Cada versão relevante deve ter uma coorte elegível e uma coorte exposta. A elegibilidade responde quem poderia usar a funcionalidade; a exposição responde quem de fato a recebeu ou descobriu. A adoção deve então distinguir primeiro uso, uso significativo, uso repetido e uso bem-sucedido. Uma grande população elegível com exposição limitada pode indicar atrito de distribuição, e não rejeição do produto.

As coortes devem preservar data de início, características da conta, contrato, segmento, geografia e linha de base relevante. A equipe deve comparar usuários expostos com uma linha de base pré-lançamento adequada ou controle quando viável. Análises de produto podem mostrar associação; alegações causais exigem desenho mais robusto e limitações declaradas.

As curvas de adoção devem ser acompanhadas por tempo suficiente para distinguir novidade de fluxo de trabalho recorrente. Uma funcionalidade usada uma vez durante o onboarding pode reduzir o tempo de implementação sem se tornar um fluxo de trabalho diário. Esse resultado ainda pode criar valor, mas deve entrar na tese de receita e retenção pelo mecanismo correto.

8. Defina o sucesso da tarefa e a aceitação do cliente

Produtos AI exigem definições de sucesso específicas do fluxo de trabalho. Uma resposta pode ser entregue dentro da meta de latência e ainda assim ser imprecisa, insegura ou inutilizável. A definição pode combinar conclusão, qualidade, confiabilidade, latência, escalonamento, esforço de revisão e aceitação do cliente. O investidor deve entender quem define o limite e como ele se relaciona à promessa contratual.

As evidências de avaliação devem cobrir condições semelhantes às de produção, em consonância com a ênfase do NIST em testes documentados e monitoramento em produção [2]. As amostras devem representar populações relevantes de clientes e modos de falha. Resultados de demonstrações curadas devem ser separados do desempenho em ambiente real. A avaliação humana deve documentar instruções, revisores, discordâncias e escalonamento.

A equipe deve rastrear falhas até suas consequências para o cliente e econômicas. Um erro de baixa severidade pode criar custo limitado; uma falha rara em um fluxo de trabalho de alto risco pode restringir o acesso ao mercado ou exigir revisão dispendiosa. A precisão agregada pode ocultar essa distribuição. O modelo de investimento deve refletir o caso de uso real e os controles residuais.

9. Construa a ponte de resultados do cliente

A ponte de resultados do cliente conecta a atividade do produto ao resultado que o comprador valoriza. Ela começa com o fluxo de trabalho contratado ou pretendido, acompanha usuários elegíveis ao longo da exposição e do uso bem-sucedido e, em seguida, testa resultados de prazo, custo, receita, risco ou qualidade. A ponte deve identificar mudanças que possam confundir a análise, como nova precificação, suporte à implementação ou dimensionamento da equipe do cliente.

As evidências podem incluir dados dos sistemas do cliente, entregáveis aceitos, níveis de serviço, decisões de renovação e estudos de caso documentados. Depoimentos sem uma linha de base fornecem contexto, mas deixam a magnitude sem esclarecimento. O investidor deve distinguir cálculos da empresa, resultados confirmados pelo cliente e evidências reproduzidas de forma independente.

A durabilidade dos resultados importa. Uma economia obtida por meio de suporte intensivo do fornecedor pode não persistir em escala. A ponte deve mostrar horas de suporte, esforço de implementação e exceções. Um cliente pode renovar por causa de um pacote mais amplo, mesmo quando o recurso AI tem baixa adoção direta. A atribuição deve permanecer proporcional às evidências.

O valor para o cliente deve ser sustentado por uma linha de base, uma coorte, evidências de aceitação, esforço de entrega e limitação declarada.

10. Analise a retenção por coorte

A retenção deve ser calculada a partir de uma população e uma base econômica definidas. A retenção de logos, a retenção de receita bruta, a retenção de receita líquida, a retenção de produto e a retenção de carga de trabalho respondem a perguntas diferentes. A equipe deve reconciliar a medida selecionada com os contratos e a receita reconhecida ou faturada, conforme apropriado.

A análise de lançamento até retenção acompanha coortes expostas a recursos relevantes e compara renovação, contração, expansão e churn. A janela de observação deve corresponder aos ciclos de contrato e de uso. Coortes recentes podem parecer saudáveis porque ainda não chegaram à renovação. Coortes maduras podem refletir um produto e um perfil de cliente mais antigos. Ambas devem ser apresentadas.

Divulgações públicas demonstram que as empresas definem e discutem a retenção com cuidado. A DigitalOcean reportou retenção líquida de dólares juntamente com lançamentos de produtos nativos do AI em seus resultados de 2025 [15]. A Atlassian identifica satisfação, lançamentos, suporte, precificação, empacotamento e ofertas AI entre os fatores que podem afetar a retenção e a expansão [16]. Essas divulgações ilustram variáveis relevantes; não estabelecem um benchmark para outra empresa.

Tabela 2. Estrutura de coortes de lançamento até retenção

Os valores são hipotéticos e ilustram apenas a estrutura de cálculo da diligência devida.

11. Diagnosticar churn e contração

A revisão de churn deve usar motivos no nível da conta respaldados por evidências. As categorias podem incluir adequação do produto, qualidade, confiabilidade, segurança, compras, integração, suporte, precificação, orçamento, concorrente, falha do cliente ou mudança estratégica. Um único motivo principal pode ser conveniente, embora oculte causas que interagem.

A equipe deve comparar o motivo declarado, o histórico de uso, o histórico de suporte, a exposição a produtos, a mudança de preços e as notas da conta. As contas perdidas devem ser segmentadas por receita, margem, setor, produto e dependência. Um pequeno número de perdas concentradas pode afetar a previsão mais do que um conjunto amplo de experimentos de baixo valor.

A contração merece análise separada. Os clientes podem manter o contrato enquanto reduzem assentos, cargas de trabalho ou recursos premium. Um recurso AI pode aumentar o engajamento sem impedir a redução de orçamento em outras áreas. A ponte de receita deve mostrar valor inicial, churn, contração, expansão, preço e efeitos cambiais usando períodos consistentes.

12. Testar a qualidade da expansão

A expansão deve estar vinculada a um impulsionador repetível. Ela pode resultar de mais usuários, maior carga de trabalho, novos produtos, preço, implementação, entidades adquiridas ou consumo temporário. O investidor deve separar compromissos contratuais do uso variável e identificar se os mesmos lançamentos que apoiam a adoção também apoiam a expansão paga.

Negócios baseados em consumo exigem cuidado adicional. A otimização do produto pode reduzir o consumo do cliente enquanto melhora o valor. Uma queda no uso não é automaticamente adversa, e o crescimento impulsionado por uso ineficiente de tokens ou computação não é automaticamente favorável. A análise deve conectar unidades de uso a resultados do cliente, preço e custo direto.

A concentração da expansão deve ser testada. Um pequeno número de grandes clientes pode criar retenção líquida atraente enquanto aumenta o poder de barganha e a volatilidade da previsão. O modelo deve mostrar a expansão por coorte, segmento e cliente, juntamente com premissas de pipeline e evidências contratuais. Premissas de venda cruzada sem suporte permanecem como entradas de cenário.

13. Conciliar a qualidade da receita

A análise da qualidade da receita deve conciliar contratos, faturamento, receita reconhecida, cobrança em caixa e evidências de produto. O IFRS 15 estabelece princípios para o reconhecimento de receita de contratos com clientes [5]. A equipe de diligência devida deve obter orientação contábil específica da transação e entender obrigações de desempenho, contraprestação variável, modificações contratuais, questões de principal e agente e componentes significativos de financiamento, quando relevantes.

Rótulos de recorrência exigem exame. A receita pode incluir implementação, desenvolvimento personalizado, revisão especializada, treinamento, suporte, repasse de marketplace ou revenda de nuvem. Esses fluxos podem ser comercialmente valiosos, embora carreguem características diferentes de margem, capital de giro e escalabilidade. O modelo deve preservar a composição.

A equipe deve testar bookings, valores anualizados e alegações de pipeline em relação aos termos executados e datas de início. O backlog contratado pode conter direitos de rescisão, variabilidade de consumo, condições de aceitação ou implantação atrasada. A cobrança em caixa deve ser analisada ao lado da receita reconhecida. Um resultado do cliente pode ser forte enquanto atrasos de compras ou de aceitação criam pressão de liquidez.

14. Alocar o custo recorrente de entrega

A análise de margem nativa de AI deve incluir os recursos necessários para entregar o resultado contratado. O custo direto pode incluir inferência de modelo, computação em nuvem, armazenamento, aquisição de dados, observabilidade, orquestração, revisão humana, implementação, suporte, créditos de serviço e licenças de terceiros. A classificação deve reconciliar com o registro contábil enquanto sustenta uma visão econômica.

Créditos promocionais, compromissos mínimos e capacidade reservada devem ser visíveis. O custo reportado durante um período de crédito pode não representar a economia sustentável. Um compromisso pode reduzir o preço unitário enquanto cria exposição a take-or-pay ou subutilização. O modelo de diligência devida deve mostrar o custo contratado e econômico sob cenários de utilização relevantes.

O documento de 2025 da Microsoft observa custos significativos de desenvolvimento e operacionais associados a modelos, serviços, plataformas e infraestrutura de AI [17]. O documento de 2025 da Alphabet descreve investimento crescente em infraestrutura técnica e custos operacionais para ofertas de AI [18]. Essas divulgações específicas do emissor apoiam a necessidade de testar a arquitetura de custos; elas não são evidência direta sobre a empresa-alvo.

15. Calcular a margem de contribuição recorrente

A margem de contribuição recorrente deve usar uma base de receita definida e um perímetro completo de custos diretos. A equipe deve calcular visões por conta, fluxo de trabalho e coorte onde os dados permitirem. A margem bruta reportada pela empresa pode ocultar um fluxo de trabalho AI não lucrativo sustentado por uma linha de produto ou serviços legada lucrativa.

A análise de bridge deve separar preço, volume, mix, tarifa do provedor, escolha de modelo, intensidade de tokens ou de carga de trabalho, cache, intervenção humana, suporte e créditos de serviço. As melhorias devem estar vinculadas a mudanças implantadas e observação sustentada. Uma projeção que assume simultaneamente menor custo de modelo e menor esforço de suporte deve explicar as evidências operacionais para ambos.

A qualidade da margem também depende do valor para o cliente. Reduzir a qualidade do modelo, o contexto ou a revisão pode diminuir o custo enquanto prejudica resultados e retenção. O investidor deve testar a fronteira eficiente entre resultado, latência, confiabilidade e custo direto. Uma única métrica de otimização não consegue representar todos os quatro.

16. Mapear a arquitetura de dependências

A arquitetura de dependências identifica os sistemas, direitos e contrapartes necessários para entregar cada fluxo de trabalho material. Ela deve abranger modelos de base, modelos proprietários, serviços de nuvem, aceleradores, dados, recuperação, armazenamentos vetoriais, observabilidade, segurança, ferramentas de avaliação, integrações, especialistas e conteúdo licenciado. Cada dependência deve estar conectada à promessa ao cliente e ao custo.

Para cada dependência, a diligência devida deve registrar provedor, contrato, prazo, renovação, mecânica de preços, compromisso de volume, nível de serviço, uso de dados, alocação de propriedade intelectual, responsabilidade, rescisão, portabilidade, alternativa, esforço de troca e limitação residual. A substituibilidade técnica e a portabilidade contratual são questões distintas.

O Perfil de AI Generativa da NIST destaca riscos ao longo do ciclo de vida da AI generativa e incentiva ações alinhadas aos objetivos organizacionais e às tolerâncias a risco [3]. O mapa de dependências converte essas preocupações em evidências de investimento. Ele deve ser mantido no nível do fluxo de trabalho porque uma empresa pode ter forte portabilidade em um produto e concentração material em outro.

Cada camada deve ser testada quanto a direitos, concentração, substituibilidade, tempo de troca e exposição econômica.

17. Avaliar a dependência de modelos de base

A dependência de modelos de base deve ser avaliada por fluxo de trabalho, e não apenas pela quantidade de provedores. Um produto pode chamar vários modelos enquanto depende de um único provedor para qualidade, latência, termos corporativos ou uma capacidade crítica. A equipe deve identificar roteamento padrão, comportamento de fallback, ajuste fino, ativos de prompt e avaliação, recursos específicos do provedor e modos de falha.

A revisão contratual deve abranger acesso, precificação, limites de taxa, compromissos de serviço, tratamento de dados, direitos de treinamento, termos de saída, indenizações, restrições territoriais, direitos de alteração e rescisão. Testes técnicos devem medir resultado e custo em alternativas viáveis. Um fallback nominal que não atende aos limites de aceitação não oferece resiliência equivalente.

O documento regulatório da Atlassian afirma que ela depende de certos modelos AI, produtos e provedores de integração de terceiros, e identifica disponibilidade, jurisdição e preço como possíveis exposições [16]. Essa divulgação pública ilustra questões relevantes para a diligência devida de dependências. O risco da empresa-alvo deve ser estabelecido a partir de sua própria arquitetura, contratos e testes.

18. Testar a substituibilidade de modelos

Os testes de substituibilidade devem usar fluxos de trabalho de produção representativos e critérios de aceitação aprovados. A equipe deve comparar qualidade dos resultados, latência, confiabilidade, segurança, tratamento de contexto, uso de ferramentas, custo, esforço de integração e controles operacionais. Uma pontuação de benchmark pode apoiar a análise, mas deixa o desempenho do fluxo de trabalho sem resolução.

O tempo de troca deve incluir compras, revisão de segurança, termos de processamento de dados, implementação, avaliação, aprovação do cliente, implantação e monitoramento. Também deve incluir o tempo necessário para reconstruir prompts, ajuste fino, recuperação ou guardrails específicos do fornecedor. A empresa deve identificar quais ativos permanecem utilizáveis após uma troca.

O modelo de investimento pode usar cenários discretos de dependência. Um cenário base pode assumir os termos comerciais atuais; um cenário negativo pode aplicar aumento de preço, limite de capacidade ou degradação de qualidade; um cenário de migração pode incluir custo operacional duplicado e lançamentos atrasados. As premissas devem ser rastreáveis e devem evitar sugerir que todas as dependências falham simultaneamente sem uma causa coerente.

Tabela 3. Scorecard de dependência e portabilidade

As pontuações devem seguir evidências documentadas e limites específicos do fluxo de trabalho.

19. Revisar alegações de modelos proprietários

As alegações de vantagem de modelos proprietários devem ser decompostas. A empresa pode ser proprietária de código de treinamento, pesos, ajustes finos, dados sintéticos, conjuntos de avaliação, roteamento, recuperação, ontologias de domínio ou feedback de fluxo de trabalho. Cada ativo tem direitos, reprodutibilidade e relevância comercial diferentes. Uma afirmação genérica de propriedade é insuficiente.

A equipe deve revisar registros de desenvolvimento, licenças, cessões de funcionários e prestadores de serviço, proveniência dos dados, permissões de treinamento, segurança e documentação do modelo. O desempenho deve ser testado em relação a uma referência relevante em condições de produção. A análise deve incluir o custo e o tempo necessários para reproduzir a vantagem alegada.

A durabilidade depende do valor para o cliente e da resposta competitiva. Uma vantagem mensurável de desempenho pode diminuir se os fornecedores melhorarem ou se os clientes aceitarem uma alternativa mais barata. Ativos proprietários também podem reduzir a dependência, ao mesmo tempo que aumentam os requisitos de treinamento, talento e capacidade computacional. O modelo de avaliação deve incorporar tanto o benefício quanto a obrigação.

20. Revisar direitos e proveniência dos dados

A diligência devida de dados deve mapear origem, propriedade, licença, consentimento, finalidade permitida, geografia, retenção, transformação, compartilhamento e exclusão. O mapa deve abranger treinamento, ajuste fino, recuperação, avaliação, monitoramento e feedback gerado pelo cliente. Direitos que sustentam uma finalidade podem não sustentar outra.

A equipe deve testar se a empresa consegue reproduzir conjuntos de dados críticos e se a linhagem sobrevive à transformação. Os dados sintéticos devem reter o método de geração e os controles de qualidade. Os dados de clientes devem ser separados de acordo com o contrato e a política. A disponibilidade pública não estabelece, por si só, um direito comercial irrestrito.

O quadro regulatório AI da Comissão Europeia descreve obrigações que variam conforme o risco e o papel do sistema AI [6]. Os Princípios AI da OCDE fornecem uma referência internacional para a gestão responsável [7]. A lei aplicável e o contrato exigem aconselhamento qualificado; o registro de investimento deve indicar quais questões foram analisadas, por quem e com quais limitações.

21. Governança da avaliação de testes

A governança de avaliação deve definir quem aprova métricas, conjuntos de dados, limiares, lançamentos e exceções. As equipes de desenvolvimento podem preparar evidências, enquanto alegações materiais sobre o produto se beneficiam de revisão independente proporcional ao risco. O registro deve preservar testes malsucedidos e explicar qualquer alteração de limiar.

A equipe deve revisar avaliação offline, testes de red team, revisão humana, monitoramento em produção e aceitação pelo cliente. Os conjuntos de teste devem representar populações materiais e modos de falha conhecidos. O vazamento entre treinamento e avaliação deve ser avaliado. O versionamento deve conectar modelo, prompt, dados, código e resultado.

O Núcleo do RMF AI do NIST afirma que conjuntos de teste, métricas e ferramentas usados durante a avaliação devem ser documentados e que a funcionalidade e o comportamento em produção devem ser monitorados [2]. O investidor deve verificar se as evidências da empresa sustentam suas promessas comerciais reais, e não uma lista de verificação genérica de conformidade.

22. Analisar segurança e resiliência

A diligência de segurança deve abranger produto, modelo, dados, infraestrutura, identidade, acesso, segredos, cadeia de suprimentos de software, integração com clientes, monitoramento, resposta a incidentes e continuidade de negócios. A equipe deve identificar quais controles são gerenciados pela empresa e quais dependem de provedores. As certificações podem apoiar as evidências, deixando o escopo e a eficácia operacional sujeitos a teste.

Cenários específicos de AI podem incluir injeção de prompt, vazamento de dados, uso inseguro de ferramentas, extração de modelo, fontes de conhecimento envenenadas, automação insegura e abuso. A análise deve se concentrar na arquitetura e no modelo de ameaças do produto. Um catálogo de riscos possíveis não é evidência de exposição nem de controle.

Incidentes, quase incidentes, vulnerabilidades e exceções devem ser vinculados à remediação, ao impacto no cliente, à notificação contratual e ao custo. Os testes de resiliência devem incluir indisponibilidade de dependências e desempenho degradado do modelo. Achados materiais podem afetar condições, indenizações, reservas, momento do investimento ou a decisão de interromper.

23. Avaliar a concentração de nuvem e de computação

A concentração de computação deve ser avaliada por provedor, região, acelerador, compromisso de capacidade e carga de trabalho. Uma empresa pode usar vários serviços de nuvem, ao mesmo tempo que depende de uma única região ou classe de hardware para um produto crítico. O mapa deve incluir cargas de trabalho de implantação, avaliação, treinamento, dados e continuidade de negócios.

A revisão contratual deve abranger preço, descontos, créditos, compromissos, capacidade, níveis de serviço, localização dos dados, segurança, rescisão e suporte à migração. A revisão técnica deve testar observabilidade, portabilidade da carga de trabalho e recuperação. O modelo financeiro deve mostrar separadamente o custo utilizado e o custo comprometido.

O documento de 2025 da CoreWeave discute adoção por clientes, desempenho, eficiência, obrigações de desempenho remanescentes e financiamento da infraestrutura AI [19]. O documento de 2026 da Oracle descreve dependências de energia, capacidade e centros de dados de terceiros [20]. Essas divulgações sobre infraestrutura ilustram condições a montante que podem chegar a uma empresa de aplicações por meio de preço, disponibilidade ou condições de fornecedores.

24. Construir a sensibilidade de computação

A sensibilidade de computação deve conectar volume de carga de trabalho, sucesso da tarefa, mix de modelos, intensidade de entrada e saída, cache, tratamento em lote, nível de latência, tarifa do provedor, créditos e compromissos mínimos. O modelo deve reconciliar com faturas e telemetria para um período selecionado. Em seguida, deve ligar-se à margem de contribuição recorrente e ao caixa.

A equipe deve evitar uma única métrica de custo por consulta quando as consultas variarem materialmente. O custo por fluxo de trabalho aceito e bem-sucedido pode oferecer uma unidade econômica mais forte, desde que o sucesso seja bem definido. O modelo também deve mostrar tentativas malsucedidas, novas tentativas, revisão humana e capacidade ociosa.

O desenho de cenários pode testar volume maior, tarifas mais baixas de provedores, migração de modelos, limites de qualidade, mix de clientes e utilização do compromisso. Cada cenário deve preservar a viabilidade operacional. Um custo menor pode exigir uma troca de qualidade; um compromisso maior pode melhorar o preço unitário enquanto aumenta o risco de caixa.

Os valores são hipotéticos e ilustram a estrutura do modelo; não são uma previsão nem uma conclusão de avaliação.

25. Avaliar a confiabilidade do produto

A confiabilidade deve ser definida por meio da promessa ao cliente. As medidas podem incluir disponibilidade, latência, taxa de erro, conclusão bem-sucedida, escalonamento, recuperação, atualidade dos dados e créditos de serviço. O tempo de atividade agregado pode ocultar um fluxo de trabalho AI com falhas dentro de um aplicativo disponível.

A equipe deve revisar objetivos de serviço, desempenho real, incidentes, causas raiz, remediação e comunicação com o cliente. A análise por release pode mostrar se a velocidade aumenta a frequência de incidentes ou reduz o tempo de recuperação. Segmentos de clientes relevantes e períodos de pico devem estar visíveis.

A economia da confiabilidade inclui receita perdida, créditos, suporte, retrabalho, capacidade duplicada e churn de clientes. A previsão deve incluir o investimento necessário para sustentar o crescimento. Um histórico de desempenho forte em escala limitada não estabelece desempenho no volume projetado; o plano de capacidade e resiliência deve explicar a ponte.

26. Avaliar a organização de produto

A diligência devida da organização deve mapear direitos de decisão, liderança, gestão de produto, engenharia, aprendizado de máquina, dados, segurança, confiabilidade, sucesso do cliente e finanças. A equipe deve testar se os responsáveis conseguem definir resultados, instrumentar o produto, revisar evidências e responder a incidentes. O número de funcionários por si só não estabelece capacidade.

A taxa de entrega de releases deve ser normalizada pelo tamanho da equipe, pela arquitetura e pela classe de mudança. A dependência de pessoas-chave deve incluir conhecimento técnico, relacionamentos com clientes e direitos de aprovação. O investidor deve revisar sucessão, retenção, incentivos, plano de contratação e exposição a contratados, respeitando os requisitos aplicáveis de emprego e privacidade.

O plano operacional deve conectar contratações a restrições específicas. Adicionar desenvolvedores pode não resolver descoberta de produto deficiente, direitos de dados ou aprovação empresarial lenta. Um cargo especializado planejado deve incluir prazo, custo e controle interino. O caso de investimento deve refletir a capacidade de execução disponível após o fechamento.

27. Revisar a concentração de clientes e o potencial de referência

A concentração de clientes deve ser medida em receita, lucro bruto, cobrança, carga de trabalho e evidências de produto. Um cliente pode representar uma parcela moderada da receita enquanto contribui com uma grande parcela dos dados de uso bem-sucedido ou da direção do produto. O investidor deve entender a concentração comercial e técnica em conjunto.

Os contratos devem ser revisados quanto a prazo, rescisão, renovação, precificação, mínimos, aceitação, nível de serviço, responsabilidade, direitos sobre dados, publicidade e mudança de controle. As chamadas de referência exigem consentimento do cliente e um conjunto controlado de perguntas. O registro deve distinguir defensores selecionados pela gestão de uma amostra representativa.

As evidências de referência devem testar a importância do problema, a implementação, o resultado, a confiabilidade, o suporte, as alternativas, a intenção de renovação e a expansão. Também devem capturar limitações e fatores específicos do cliente. Uma única referência entusiasmada não pode estabelecer a retenção de toda a carteira. As conclusões devem conciliar com registros de uso, suporte e comerciais quando permitido.

28. Analisar o mercado e a posição competitiva

A diligência devida de mercado deve definir o problema do cliente, o comprador econômico, o usuário, o orçamento, o processo de compra e alternativas credíveis. Empresas nativas de AI podem competir com fornecedores de software, desenvolvimento interno, serviços terceirizados, provedores de modelos ou trabalho manual contínuo. O tamanho do mercado deve seguir fluxos de trabalho endereçáveis e a disposição a pagar.

As evidências competitivas devem comparar o resultado para o cliente, a qualidade, a integração, a segurança, a implantação, o preço, o custo direto e a mudança de fornecedor. A contagem de funcionalidades pode enganar porque as capacidades diferem em prontidão para produção e aceitação pelo cliente. A equipe deve revisar registros de vitórias e derrotas, referências de concorrentes e decisões de renovação, preservando as limitações da amostra.

A tese de investimento deve indicar onde reside a vantagem e como ela pode mudar. Melhorias dos provedores podem fortalecer o produto ou comprimir a diferenciação. Modelos abertos podem reduzir custos ou aumentar a concorrência. A regulamentação pode elevar barreiras e custos de conformidade. Os cenários devem conectar essas forças aos resultados dos clientes, à retenção e à margem.

29. Testar precificação e empacotamento

A diligência devida de precificação deve mapear a unidade de cobrança para o valor do cliente e o custo da empresa. Estruturas por assento, fluxo de trabalho, resultado, assinatura, consumo e híbridas distribuem o risco de forma diferente. A equipe deve examinar preço de tabela, preço realizado, descontos, créditos, mínimos, excedentes, serviços e mecânica de renovação por coorte.

O empacotamento deve mostrar quais funcionalidades impulsionam aquisição, adoção, expansão e retenção. Funcionalidades AI oferecidas a preço incremental baixo ou nulo podem sustentar uma plataforma mais ampla enquanto aumentam o custo de hospedagem, como a Atlassian descreve como risco em seu documento de registro [16]. Essa declaração específica do emissor ilustra a necessidade de testar a economia dos pacotes da empresa-alvo.

Os experimentos de preço devem ser separados dos resultados contratados. O investidor deve testar a disposição a pagar, a resposta do setor de compras, a elasticidade de uso e o churn. Uma projeção que assume preço mais alto e adoção maior deve explicar o valor para o cliente e o plano de transição. Mudanças de preço também podem alterar requisitos de suporte, canal e reconhecimento de receita.

30. Avaliar a repetibilidade da estratégia de entrada no mercado

A análise de entrada no mercado deve rastrear conta-alvo, oportunidade qualificada, validação técnica, revisão de segurança, aprovação comercial, implementação, adoção e renovação. O tempo de ciclo deve ser segmentado por cliente e caso de uso. Produtos AI podem enfrentar longas etapas de avaliação e governança mesmo quando as demonstrações são rápidas.

A equipe deve conciliar registros de relacionamento com clientes, contratos, telemetria de produto, registros de implementação e receita. As etapas do pipeline devem ter critérios de saída baseados em evidências. Rotas originadas por parceiros, lideradas por fundadores e de autoatendimento devem ser mostradas separadamente porque a capacidade e a conversão podem diferir.

A repetibilidade exige mais do que crescimento histórico. A empresa deve mostrar um problema definido, um resultado que possa ser referenciado, uma implantação viável, capacidade de suporte e economia unitária em coortes sucessivas. A projeção deve incluir recursos de vendas, engenharia de soluções, segurança, implementação e sucesso do cliente necessários para reproduzir esse movimento.

31. Construir a projeção a partir dos direcionadores operacionais

A projeção deve começar pelas coortes de clientes e pelos direcionadores operacionais. Clientes iniciais, novas aquisições, ativação, uso recorrente bem-sucedido, renovação, contração, expansão, preço e momento da receita formam a ponte comercial. Carga de trabalho, mix de modelos, tarifas de fornecedores, suporte e implementação formam a ponte de custos.

Cada premissa deve ter uma fonte, um período-base e um responsável. Evidências históricas podem sustentar um intervalo em vez de um ponto. Mudanças recentes de produto podem não ter dados maduros de renovação. O modelo deve indicar onde o julgamento da administração vai além da evidência observada e deve preservar os casos alternativos.

O balanço patrimonial e a demonstração do fluxo de caixa devem seguir o modelo operacional. Receita diferida, contas a receber, compromissos com fornecedores, desenvolvimento capitalizado, arrendamentos, dívida, impostos e custos de transação podem afetar a liquidez. A projeção deve conciliar com as políticas contábeis e receber revisão qualificada quando necessário.

Tabela 4. Mapa de evidências das premissas de projeção

Cada premissa deve manter uma fonte, período de observação e faixa de cenário aprovada.

32. Construir cenários coerentes

Os cenários devem descrever estados operacionais internamente consistentes. Um cenário-base pode assumir aceitação atual do produto, retenção medida e contratações planejadas. Um cenário positivo pode combinar adoção mais forte com eficiência comprovada no suporte. Um cenário negativo pode combinar implantação empresarial mais lenta, renovação mais fraca e custo de modelo mais alto. Cada caso deve especificar o mecanismo.

A equipe deve evitar misturar todas as premissas favoráveis em um único caso sem dependências operacionais. Lançamentos mais rápidos podem exigir mais capacidade de avaliação e confiabilidade. Volume maior de clientes pode aumentar o suporte e o capital de giro antes que a eficiência apareça. Preços mais baixos de fornecedores podem atrair concorrentes, além de melhorar a margem.

As probabilidades dos cenários devem ser usadas com cuidado. Quando as evidências forem limitadas, intervalos e limiares de decisão podem ser mais transparentes. O comitê de investimentos deve ver quais premissas impulsionam o valor do título, a necessidade de capital e o retorno. A análise de sensibilidade não deve substituir uma narrativa coerente sobre como o negócio opera.

33. Determinar a necessidade de capital e o runway

A necessidade de capital deve abranger desde a assinatura até um próximo financiamento crível, um ponto de autofinanciamento ou uma decisão estratégica. Deve incluir caixa operacional, compromissos com fornecedores, capital de giro, custos de transação, serviço da dívida, pagamentos contingentes e uma reserva de liquidez. O modelo deve usar os termos efetivos do título e as condições de fechamento.

O plano de diligência devida deve identificar marcos de evidência que exigem tempo e caixa. Renovações empresariais, migrações de modelo, certificações e expansão de mercado podem se estender além do runway proposto. Um título escalonado pode alinhar o financiamento às evidências, ao mesmo tempo que introduz considerações de execução e controle que exigem aconselhamento jurídico e tributário.

O runway deve ser testado sob receita atrasada, custo mais alto e risco de fechamento. Um term sheet assinado não fornece caixa. A empresa pode precisar de capacidade para operar durante documentação, aprovações e recebimento. O investidor também deve entender se a confiança de clientes ou fornecedores depende da solidez do balanço.

34. Traduzir os achados em avaliação

A avaliação deve seguir a finalidade, a base, os métodos, as evidências e os direitos do título. A IFRS 13 define valor justo como uma mensuração baseada no mercado e estabelece uma estrutura para mensuração e divulgação [4]. As Normas Internacionais de Avaliação fornecem normas relevantes para trabalhos de avaliação [8]. Pode ser necessário aconselhamento qualificado específico à transação.

As abordagens de mercado podem usar empresas e transações comparáveis, com ajustes sustentados por diferenças em crescimento, retenção, margem, concentração, intensidade de capital, direitos e risco. As abordagens de renda podem traduzir evidências de coorte e de custo em fluxos de caixa. Um financiamento recente pode fornecer contexto, embora exija revisão de direitos e condições de mercado.

Os achados de diligência devida devem entrar no modelo por meio de direcionadores explícitos. Uma coorte retida madura pode afetar a durabilidade da receita; a concentração de modelo pode afetar margem, necessidade de capital ou intervalo de cenários; achados sobre títulos podem afetar condições de fechamento e investimento. Descontos arbitrários podem contar em dobro efeitos já capturados na projeção.

35. Modelar o waterfall de distribuição dos títulos

O valor da empresa não determina o valor atual para os acionistas sem a estrutura de capital. O modelo deve incluir caixa, dívida, conversíveis, preferências, participação, antidiluição, warrants, opções, mudanças no pool, tranches e custos de transação. As definições devem seguir os documentos efetivos e a revisão jurídica qualificada.

O waterfall deve mostrar os recursos em cenários de valor da empresa e convertê-los em participação acionária, retorno e potencial de queda para o investidor. Novo financiamento pode melhorar o valor operacional enquanto altera a alocação entre títulos. Tranches por marco, preferências de liquidação e direitos de governança podem afetar tanto a proteção quanto os incentivos.

O comitê deve avaliar preço e termos em conjunto. Uma avaliação nominal mais alta com direitos econômicos seniores pode produzir um resultado diferente de um preço mais baixo com termos mais simples. O pacote de decisão deve manter a fonte da tabela de capitalização, as premissas e a sensibilidade para que o resultado possa ser reproduzido.

36. Estruturar proteções do investimento

As proteções devem responder a riscos materiais e comprovados. Podem incluir condições precedentes, financiamento escalonado, direitos de informação, direitos no conselho, matérias reservadas, covenants, controles de uso dos recursos, disposições sobre pessoas-chave, declarações, indenizações ou planos específicos de remediação. Sua viabilidade e efeito exigem assessoria jurídica, regulatória e tributária.

A equipe deve evitar usar termos como substituto para a compreensão do negócio. Um covenant não pode criar valor para o cliente nem portabilidade do modelo. Ele pode fornecer direitos de informação, consentimento ou intervenção, ao mesmo tempo que pode restringir a operação e o financiamento futuro. Cada proteção deve ter um risco definido, gatilho, medida corretiva e fonte de monitoramento.

As condições de fechamento devem ser passíveis de verificação objetiva. Requisitos vagos de tecnologia aprimorada ou desempenho satisfatório podem gerar disputas. Evidências do registro de diligência devida podem sustentar entregáveis específicos, testes de aceitação e aprovação final autorizada. Os riscos residuais devem permanecer na recomendação de investimento.

37. Construir o scorecard de investimento

O scorecard de investimento deve combinar força das evidências, resultado operacional, consequência financeira e resposta proposta. Deve evitar um total único e opaco que oculte uma questão fatal. As categorias podem incluir valor para o cliente, retenção, economia, dependência, direitos sobre dados, segurança, equipe, mercado, previsão, liquidez e termos de garantia.

Cada pontuação deve seguir uma rubrica aprovada e vincular-se às evidências subjacentes. O comitê deve ver confiança e limitação separadamente do resultado. Um resultado observado forte apoiado por uma pequena amostra difere de um resultado fraco apoiado por uma população completa. Ambas as dimensões importam.

O scorecard deve apoiar o julgamento, não automatizá-lo. Os tomadores de decisão devem registrar motivos, discordâncias, condições e questões não resolvidas. As alterações entre a revisão inicial, a aprovação final e o fechamento devem ser versionadas. O registro pode então apoiar a governança pós-investimento.

O comitê deve considerar resultado operacional, confiança das evidências, limitação, efeito sobre o valor e ação proposta.

Tabela 5. Campos do scorecard de investimento

Uma pontuação não se sobrepõe a uma condição impeditiva material nem a um parecer especializado.

38. Prepare o material do comitê de investimentos

O material do comitê deve indicar a decisão solicitada, o instrumento, a faixa de preço, os recursos da operação, a participação, a governança, os cenários de retorno e as condições. Em seguida, deve apresentar a tese operacional, a cadeia de evidências, as constatações materiais, o modelo de cenários, a necessidade de capital, o waterfall de distribuição, as proteções, as limitações e a recomendação. Os anexos devem manter o registro detalhado e os relatórios de especialistas.

O material deve distinguir fato, cálculo testado, declaração da administração e cenário. As datas e versões das fontes importam porque as evidências de produto e financeiras podem mudar durante um processo. Mudanças materiais após a circulação devem ser destacadas, e não incorporadas silenciosamente.

O comitê deve receber tempo suficiente para contestar as premissas. Perguntas e respostas devem integrar o registro de decisão. A aprovação deve identificar a autoridade delegada para a negociação final e definir as mudanças que exigem nova aprovação. Uma faixa de avaliação sem limites dos termos ou condições de fechamento deixa o mandato incompleto.

O material deve incluir uma ponte clara entre a tese inicial e a recomendação final. Toda mudança material deve identificar a evidência que a causou, a variável de entrada do modelo afetada e a resposta proposta ao comitê. Essa disciplina ajuda os revisores a distinguir aprendizado genuíno de movimentos inexplicados na faixa de avaliação. Também reduz o risco de que evidências operacionais favoráveis sejam incorporadas rapidamente enquanto constatações adversas permaneçam isoladas em anexos de especialistas.

As conclusões dos especialistas devem manter seu escopo. Um revisor técnico pode confirmar que um modelo alternativo passa em um teste definido, deixando a portabilidade contratual, o consentimento do cliente e o custo de migração para outros assessores. O material integrado deve conectar esses limites sem sugerir asseguração mais ampla. Pareceres jurídicos, fiscais, contábeis, de segurança cibernética e de avaliação devem ser atribuídos ao prestador qualificado e usados dentro de suas premissas declaradas.

39. Estabeleça o monitoramento pós-investimento

O monitoramento pós-investimento deve dar continuidade à arquitetura de evidências da diligência devida. A empresa pode reportar, em uma cadência controlada, aceite de versão, uso recorrente bem-sucedido, retenção, custo direto, exposição a dependências, incidentes, caixa, projeções e status de covenant. As definições devem permanecer estáveis ou apresentar uma ponte documentada.

O reporte ao conselho deve concentrar-se em limites vinculados à tese de investimento. Um aumento nos lançamentos pode ser favorável se o sucesso do cliente e a confiabilidade se mantiverem. Pode exigir intervenção se o suporte, os incidentes ou o churn aumentarem. Testes de dependência e renovações de contratos devem ser programados antes que as opções de troca fiquem restritas.

O investidor deve acompanhar os compromissos de remediação, o uso dos recursos e os marcos de financiamento. As exceções devem ter responsáveis e prazos. O monitoramento deve permanecer proporcional e respeitar a autoridade da administração, a confidencialidade e a legislação aplicável. O objetivo é evidência para decisão oportuna, não duplicação operacional.

O desenho do monitoramento deve abordar a deriva de métricas. À medida que produtos, preços e segmentos de clientes mudam, a administração pode precisar revisar definições. O material do conselho deve manter a métrica anterior, a métrica revisada, o motivo da mudança e uma ponte para períodos comparáveis quando praticável. Uma métrica que melhora após uma mudança de denominador não deve ser apresentada como progresso operacional sem a reconciliação.

O investidor também deve programar decisões sobre dependências antes do vencimento do contrato ou da renovação de capacidade. Um teste de migração tem valor limitado quando o prazo remanescente é curto demais para executá-lo. Controles de calendário podem conectar renovação de fornecedores, compromissos com clientes, gatilhos de liquidez e roteiros de produtos. Isso torna a opcionalidade observável e dá ao conselho tempo para aprovar uma troca, negociar proteção, financiar a duplicação ou aceitar a exposição com uma justificativa documentada.

40. Conclusão

A diligência de capital de crescimento nativa da AI deve seguir a cadeia completa do lançamento ao valor para o cliente, à retenção, à economia recorrente e ao resultado de segurança. A velocidade do produto fornece evidências úteis quando os lançamentos são definidos, testados, adotados e associados a fluxos de trabalho duráveis. Registros de clientes e financeiros devem completar a ponte.

Dependências de modelos, dados, nuvem e computação moldam qualidade, continuidade, margem e necessidade de capital. Elas devem ser mapeadas no nível do fluxo de trabalho e testadas por meio de contratos, avaliação semelhante à de produção e planos de migração viáveis. Alegações não comprovadas de portabilidade ou vantagem proprietária devem permanecer como limitações.

O comitê de investimentos precisa de um registro de decisão reproduzível. O registro de evidências, os cenários coerentes, a ponte de avaliação, a cascata de segurança e o scorecard conectam a diligência devida a preço, termos, governança, ação ou interrupção. Eles também criam uma linha de base controlada para o monitoramento pós-investimento. A decisão final permanece específica aos fatos e exige julgamento profissional e assessoria especializada.

Um processo disciplinado deve permanecer utilizável sob pressão de tempo. Responsáveis nomeados, fontes datadas, cálculos controlados e direitos de decisão explícitos permitem que a equipe atualize as evidências sem reconstruir todo o caso. Essa disciplina operacional pode melhorar a prontidão para negociação, o controle de fechamento e a qualidade das primeiras decisões do conselho após o investimento.

Referências

1. Instituto Nacional de Padrões e Tecnologia, Estrutura de Gestão de Riscos de Inteligência Artificial 1.0, https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10
2. Instituto Nacional de Padrões e Tecnologia, Núcleo do RMF de AI, https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
3. Instituto Nacional de Padrões e Tecnologia, Estrutura de Gestão de Riscos de Inteligência Artificial: Perfil de Inteligência Artificial Generativa, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
4. Fundação IFRS, IFRS 13 Mensuração do Valor Justo, https://www.ifrs.org/issued-standards/list-of-standards/ifrs-13-fair-value-measurement/
5. Fundação IFRS, IFRS 15 Receita de Contratos com Clientes, https://www.ifrs.org/issued-standards/list-of-standards/ifrs-15-revenue-from-contracts-with-customers/
6. Comissão Europeia, Estrutura regulatória para a inteligência artificial, https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
7. Organização para a Cooperação e Desenvolvimento Econômico, Princípios AI da OCDE, https://oecd.ai/en/ai-principles
8. Conselho Internacional de Normas de Avaliação, Normas Internacionais de Avaliação, https://www.ivsc.org/standards/
9. Organização Internacional de Normalização, sistemas de gestão de inteligência artificial ISO/IEC 42001, https://www.iso.org/standard/81230.html
10. U.S. Securities and Exchange Commission, Base de dados de registros de empresas do EDGAR, https://www.sec.gov/edgar/search/
11. U.S. Securities and Exchange Commission, Observações na Mesa-Redonda sobre Inteligência Artificial no Setor Financeiro, 27 de março de 2025, https://www.sec.gov/newsroom/speeches-statements/crenshaw-remarks-ai-roundtable-032725
12. Financial Accounting Standards Board, Tópico 606 da Codificação de Normas Contábeis, https://asc.fasb.org/topic&trid=2129938
13. Banco de Compensações Internacionais, publicações sobre o tema inteligência artificial, https://www.bis.org/topic/artificial_intelligence.htm
14. Amplitude Inc., relatórios anuais e documentos apresentados à SEC, https://investors.amplitude.com/financial-information/sec-filings
15. DigitalOcean Holdings Inc., resultados do quarto trimestre e anuais de 2025 arquivados na SEC, https://www.sec.gov/Archives/edgar/data/1582961/000158296126000015/a2025-q4dopressrelease.htm
16. Atlassian Corporation, relatório anual de 2025, https://www.sec.gov/Archives/edgar/data/1650372/000165037225000060/team2025annualreport.pdf
17. Microsoft Corporation, relatório anual de 2025 arquivado na SEC, https://www.sec.gov/Archives/edgar/data/789019/000095017025100235/msft-20250630.htm
18. Alphabet Inc., relatório anual de 2025 arquivado na SEC, https://www.sec.gov/Archives/edgar/data/1652044/000165204426000018/goog-20251231.htm
19. CoreWeave Inc., relatório anual de 2025 arquivado na SEC, https://www.sec.gov/Archives/edgar/data/1769628/000176962826000104/crwv-20251231.htm
20. Oracle Corporation, relatório anual de 2026 arquivado na SEC, https://www.sec.gov/Archives/edgar/data/1341439/000119312526277521/orcl-20260531.htm
21. Snowflake Inc., relatórios anuais e documentos arquivados na SEC, https://investors.snowflake.com/financials/sec-filings/default.aspx
22. C3.AI Inc., relatórios anuais e documentos arquivados na SEC, https://ir.c3.ai/financials/sec-filings/default.aspx
23. NVIDIA Corporation, relatórios financeiros e documentos arquivados na SEC, https://investor.nvidia.com/financial-info/financial-reports-and-sec-filings/default.aspx
24. Instituto Nacional de Padrões e Tecnologia, AI Manual do RMF, https://airc.nist.gov/airmf-resources/playbook/
25. National Institute of Standards and Technology, Estrutura TEVV-Athlon para Avaliação de Sistemas AI, https://www.nist.gov/artificial-intelligence/ai-research/tevv-athlon-framework-evaluating-ai-systems
26. IFRS Foundation, material educacional sobre mensuração do valor justo de instrumentos de capital próprio não cotados, https://www.ifrs.org/content/dam/ifrs/supporting-implementation/ifrs-13/education-ifrs-13-eng.pdf