Porque o software ESG foi mal concebido
A indústria do software de sustentabilidade tem um problema de 30 mil milhões de dólares, e não é aquele em que toda a gente pensa.
Não é um problema de qualidade dos dados. Não é um problema de regulamentação. Nem sequer é um problema de talento.
É um problema de arquitetura. E quase ninguém fala dele.
O pecado original
Quando surgiu a primeira vaga de software ESG, foi desenhada para responder a uma única pergunta: como preenchemos este relatório?
Parece razoável. As empresas enfrentavam novas obrigações de divulgação (GRI, CDP, as primeiras versões do que viria a ser a CSRD) e precisavam de ferramentas para compilar informação e produzir documentos. O mercado respondeu como responde sempre perante um prazo de conformidade: com ferramentas de reporte feitas à medida.
Eis o problema. Construir software em torno de um framework de reporte significa herdar a estrutura desse framework como arquitetura de dados. O seu modelo de dados não é moldado pela forma como os dados de sustentabilidade se comportam realmente dentro de uma organização. É moldado pela forma como um framework específico decidiu fazer perguntas num determinado ano.
A arquitetura centrada no framework é o pecado original do software ESG. Tudo o que hoje frustra as empresas decorre daí.
A indústria não construiu apenas o produto errado. Construiu a fundação errada. E depois passou uma década a mobilar um edifício com fissuras estruturais.
A armadilha do framework
Pense no que acontece quando uma empresa adota uma plataforma ESG típica.
A ferramenta pergunta: qual é o valor das suas emissões de âmbito 1? A empresa introduz um número. A ferramenta associa-o à célula certa do framework certo. Relatório gerado. Conformidade alcançada.
Agora um segundo framework pede os mesmos dados de base, mas estruturados de outra forma. Um terceiro pede dados sobrepostos, mas não idênticos. Um investidor solicita um corte personalizado. Uma equipa interna precisa dos dados em bruto para decisões operacionais.
A plataforma não consegue servir nenhum destes pedidos sem retrabalho, porque os dados foram captados para um framework, e não como evidência estruturada que possa ser reutilizada em qualquer saída.
Esta é a armadilha do framework: quantos mais frameworks se suportam, mais captura redundante de dados se cria e mais frágil se torna todo o sistema. Cada novo pedido de reporte não simplifica: multiplica o trabalho.
A maioria das empresas só se apercebe de que está nesta armadilha quando gere três ou quatro frameworks em simultâneo e gasta mais tempo a reconciliar números entre relatórios do que a melhorar o desempenho. Nessa altura, já construíram anos de conhecimento institucional sobre uma fundação quebrada.
O erro de categoria
Isto não é uma falta de funcionalidades. É um erro de categoria.
Uma ferramenta de reporte recebe entradas e produz uma saída formatada. O seu valor está na última milha: o documento, a submissão, o PDF. Os dados existem para servir o relatório.
A infraestrutura de dados faz o contrário. Capta a evidência uma só vez, estrutura-a na origem e disponibiliza-a a qualquer processo a jusante (o reporte incluído, mas não só). O relatório é uma de muitas saídas possíveis. O valor está na arquitetura, não no documento.
A distinção:
Centrada no framework (o que a indústria construiu): dados, modelo do framework, PDF. Repetido por cada framework. Reconciliado manualmente. Quebra quando algo muda.
Centrada na arquitetura (o que deveria ter sido construído): evidência, camada de dados estruturada, saídas ilimitadas. Captada uma só vez. Mapeada de forma dinâmica. Escala com a complexidade.
No primeiro modelo, os dados são moldados pela pergunta. No segundo, a pergunta é moldada pelos dados.
A indústria confundiu a geração de documentos com o desenho de dados. Construiu software de tradução quando precisava de construir um sistema operativo de dados.
Porque aconteceu
Não foi estupidez. Foi a estrutura de incentivos.
Os compradores do software ESG de primeira geração eram equipas de sustentabilidade com prazos de conformidade. O seu sucesso media-se pelos relatórios entregues a tempo. Não precisavam de infraestrutura, precisavam de resultados. Depressa.
Por isso, os fornecedores otimizaram o tempo até ao relatório. Ingerir os dados no formato que o cliente tivesse, associá-los ao framework, gerar o relatório. Entregar. Renovar o contrato.
Isto criou um mercado em que todos os fornecedores competiam pela cobertura de frameworks. Quem suporta a CSRD? Quem suporta o CBAM? Quem incluiu primeiro a análise de dupla materialidade? A corrida para cobrir mais frameworks só aprofundou a dívida arquitetónica subjacente.
Ninguém parou para perguntar: e se a camada de dados fosse independente de qualquer framework?
Ninguém perguntou porque ninguém tinha incentivo para o fazer. A equipa de sustentabilidade queria relatórios. O fornecedor queria renovações. O regulador queria divulgações. A urgência da conformidade criou dívida arquitetónica à escala da indústria.
O custo composto
Todos os anos, a superfície de requisitos regulatórios (e de pedidos de clientes) aumenta. Cada novo framework acrescenta mais um ciclo de captura. Cada ciclo acrescenta mais um fardo de reconciliação. O custo não cresce de forma linear: cresce de forma geométrica.
Captura redundante. O mesmo dado (o consumo de energia de uma instalação) é recolhido, formatado, validado e introduzido várias vezes para vários frameworks. Cada instância introduz variação. Os dados não estão errados, propriamente. Simplesmente nunca são a fonte de referência.
Fragilidade estrutural. Quando um framework muda, todo o circuito se parte. Não porque a realidade subjacente tenha mudado, mas porque a camada de mapeamento está codificada para uma versão específica de uma norma específica. Uma atualização de framework deveria ser uma alteração de configuração. Em vez disso, é uma migração.
Sem valor operacional. Os dados fechados numa estrutura de reporte não podem informar decisões. Não é possível fazer análise de cenários com números presos num modelo da CSRD. Não é possível otimizar as compras com dados captados para o CDP. Os dados de sustentabilidade ficam em silos, desligados dos sistemas operacionais que realmente os poderiam usar.
Exposição em auditoria. Quando o mesmo número aparece em três relatórios com três valores ligeiramente diferentes, não tem um problema de dados. Tem um problema de governação. E a garantia obrigatória está prestes a pô-lo a descoberto.
Toda uma categoria de software está a agravar a sua própria fragilidade. E a ferramenta de reporte, pelo seu desenho, não tem qualquer mecanismo para achatar essa curva.
O que a arquitetura deveria ter sido
O princípio: captar uma vez, estruturar na origem, reutilizar sem limite.
Uma empresa gera constantemente evidência relevante para a sustentabilidade: faturas, contas de serviços, leituras de sensores, declarações de fornecedores, registos de recursos humanos, dados de compras e mais. Essa evidência existe quer um framework a peça ou não. A tarefa do software não é pedir à empresa que volte a introduzir essa evidência num formulário moldado por um framework. A tarefa é ingerir a evidência na sua forma bruta, estruturá-la segundo um modelo de dados universal e depois convertê-la na saída que for necessária.
O framework passa a ser uma camada de apresentação, não um modelo de dados. O relatório passa a ser uma vista, não um destino.
Esta é a arquitetura de captura única. Um ponto de ingestão por fonte de dados. Uma representação estruturada por unidade de evidência. Saídas ilimitadas.
Acrescentar um novo framework passa a ser uma configuração de mapeamento, não um projeto de recolha de dados. Atualizar a versão de um framework passa a ser uma alteração de esquema, não uma migração. Responder a um pedido pontual de um cliente passa a ser uma consulta, não um sprint de três semanas.
O custo marginal do framework seguinte aproxima-se de zero. Os dados passam a ser auditáveis por defeito, uma única fonte de referência em vez de quinze cópias. E, sobretudo, os dados passam a estar disponíveis para uso operacional, porque não estão fechados dentro de um relatório.
Esta não é uma de várias abordagens possíveis. É a única arquitetura que sobrevive aos próximos cinco anos de expansão regulatória sem se quebrar. É também a base da rastreabilidade das evidências de que as auditorias exigem cada vez mais.
Porque os agentes são impossíveis sem isto
É aqui que o argumento se torna binário.
O modelo atual pressupõe fluxos de trabalho conduzidos por pessoas: uma pessoa recolhe os dados, valida-os, mapeia-os, gera o relatório. O software automatiza alguns passos, mas a arquitetura cognitiva continua a ser manual.
Este modelo tem um teto. A superfície de complexidade (mais frameworks, mais granularidade, mais jurisdições, mais requisitos de garantia) cresce mais depressa do que as equipas conseguem contratar. O modelo manual não aguenta o ritmo. Esse momento não é teórico. Está a chegar.
O único sistema capaz de absorver esta complexidade sem um crescimento proporcional de pessoal é o sistema com agentes: agentes de software que compreendem o modelo de dados, monitorizam os fluxos de evidência, assinalam lacunas, executam mapeamentos e geram saídas de forma autónoma.
Mas há uma dependência que o mercado ignora: os agentes não são uma melhoria que se acrescenta ao software existente. São estruturalmente impossíveis sem correção arquitetónica.
Um agente precisa de um modelo de dados coerente sobre o qual raciocinar. Precisa de percorrer as relações entre instalações, fornecedores, períodos temporais e fontes de evidência. Precisa de rastrear qualquer número até à sua origem, avaliar a confiança, identificar o que falta e determinar como o resolver.
Nada disto funciona com dados moldados por um framework. Um agente que olha para uma célula de âmbito 3 num modelo da CSRD vê um número. Não vê a evidência da cadeia de abastecimento que o produziu, a metodologia aplicada, o nível de confiança nem as lacunas de cobertura. O agente fica cego, não porque a IA não seja capaz, mas porque a estrutura de dados não lhe dá nada por onde navegar.
A equação é binária:
Arquitetura moldada pelo framework: sem agentes com significado. Nunca. Pode acrescentar chatbots, geradores de rascunhos, IA cosmética. Mas não pode implementar agentes que giram de forma autónoma o ciclo de vida da evidência, porque a arquitetura não suporta o raciocínio.
Arquitetura baseada em evidência: os agentes tornam-se inevitáveis. Quando a camada de dados é estruturada, coerente e independente de frameworks, implementar agentes é uma consequência natural. A arquitetura convida à ação autónoma porque oferece tudo o que um agente precisa: evidência estruturada, linhagem completa, relações semânticas e consciência das lacunas.
É assim um espaço de trabalho com agentes. Não são funcionalidades de IA coladas a uma ferramenta de reporte, mas uma arquitetura de dados em que a evidência vive uma só vez, é estruturada uma só vez e agentes inteligentes gerem tudo, da ingestão à divulgação. O espaço de trabalho não é a interface. É a camada de dados.
As empresas que construíram ferramentas de reporte não podem acoplar agentes à sua arquitetura atual. Teriam de reconstruir a partir da fundação. O que significa admitir que a arquitetura estava errada desde o início.
A bifurcação
O mercado do software de sustentabilidade divide-se exatamente por esta linha.
De um lado: ferramentas de reporte que competem na cobertura de frameworks e disputam margens cada vez menores à medida que os frameworks convergem e se simplificam. A sua vantagem competitiva erode-se sempre que um regulador consolida requisitos, porque a simplificação elimina a complexidade que foram construídas para gerir. Sem caminho para capacidade com agentes. Custo crescente por saída. Um teto de valor.
Do outro: infraestrutura de dados que trata a evidência de sustentabilidade como um ativo de dados de primeira classe, independente de qualquer saída regulatória. O valor aumenta com cada novo framework, cada novo pedido de uma parte interessada, cada novo caso de uso, porque o custo marginal de uma nova saída a partir de dados estruturados é quase nulo. E a arquitetura suporta naturalmente os sistemas com agentes que a próxima década exige.
Uma arquitetura fica mais cara à medida que a complexidade cresce. A outra capitaliza.
A escolha
A indústria do software ESG otimizou a saída quando devia ter otimizado a arquitetura. A urgência da conformidade criou dívida arquitetónica à escala da indústria. O resultado é uma categoria inteira de software que agrava, de forma progressiva, o problema que foi concebida para resolver.
A solução não são melhores ferramentas de reporte. Não são mais conectores, mais modelos, mais tradutores de frameworks. Não é um copiloto de IA colocado sobre um modelo de dados quebrado.
A solução é reconstruir a partir da camada de dados. Captura única. Evidência estruturada. Arquitetura independente de frameworks. Execução com agentes.
As empresas que reconstruírem a sua camada de dados transformarão a conformidade num subproduto e a complexidade regulatória em alavanca. As que não o fizerem continuarão a contratar analistas para reconciliar folhas de cálculo, enquanto a complexidade que tentam gerir cresce mais depressa do que conseguem contratar.
Não é uma escolha entre dois produtos. É uma escolha entre dois futuros.
Quer ver software de sustentabilidade com arquitetura em primeiro lugar? Peça uma demo e descubra como funciona a arquitetura de captura única da Dcycle.
