@SpaceandTime A IA começou a comprar dados por conta própria, mas nem sabe quando erra nos cálculos
Nos últimos dois dias, conectei um agente de consulta de dados a um ambiente de demonstração e testei dezenas de perguntas. O que mais incomoda não é ele dar respostas erradas, mas o tom ser exatamente o mesmo quando acerta e quando erra. A versão Enterprise lançada pela Space and Time em 9 de novembro ataca justamente esse problema. A lógica é simples: o cálculo é feito em dados privados, gerando um recibo criptográfico Proof of SQL. Antes de alimentar o agente com o resultado, o aplicativo verifica esse recibo; só depois deixa o agente agir. Os dados não saem do banco e o processo de cálculo pode ser conferido. Essa promessa vai ficar muito valiosa agora que os agentes começaram a fazer chamadas de API por conta própria. O caminho que testei foi conectar uma tabela de negócios, enviar uma consulta pelo SDK, obter o resultado e a prova e, depois, validá-la em um contrato on-chain. Levei mais ou menos uma tarde para fazer tudo funcionar pela primeira vez. O obstáculo não foi a criptografia, mas a configuração do ambiente e a necessidade de decidir primeiro qual tabela vale a pena comprovar. Essa barreira existe de verdade, mas, em troca, você ganha algo muito concreto: a correção do resultado deixa de depender de em quem você confia. Comparado a soluções de feeds de preços como a Chainlink, que informam qual é o valor de algo neste momento, o SXT mostra qual critério foi usado e em que tabela o valor foi calculado. Comparado a painéis somente de leitura como o Dune, a diferença é que este último só pode fornecer uma captura de tela, enquanto o primeiro pode fornecer um recibo. É só uma questão de tempo até que uma IA tome uma decisão com base em uma captura de tela e algo dê errado. Houve também um efeito colateral que eu não tinha previsto no começo. Com as provas, cada decisão do agente pode ser reproduzida. Se algo der errado, dá para identificar qual consulta usou quais dados; responsabilizar alguém fica mais simples do que vasculhar logs, embora também custe mais. Por isso, não me importo muito com o quanto a história que contam sobre isso está em alta agora. O que me importa é: quando os agentes realmente começarem a chamar APIs e gastar dinheiro para comprar dados, quem vai cobrar pedágio nessa camada dos recibos? #sxt $SXT
Nos últimos dois dias, conectei um agente de consulta de dados a um ambiente de demonstração e testei dezenas de perguntas. O que mais incomoda não é ele dar respostas erradas, mas o tom ser exatamente o mesmo quando acerta e quando erra. A versão Enterprise lançada pela Space and Time em 9 de novembro ataca justamente esse problema. A lógica é simples: o cálculo é feito em dados privados, gerando um recibo criptográfico Proof of SQL. Antes de alimentar o agente com o resultado, o aplicativo verifica esse recibo; só depois deixa o agente agir. Os dados não saem do banco e o processo de cálculo pode ser conferido. Essa promessa vai ficar muito valiosa agora que os agentes começaram a fazer chamadas de API por conta própria. O caminho que testei foi conectar uma tabela de negócios, enviar uma consulta pelo SDK, obter o resultado e a prova e, depois, validá-la em um contrato on-chain. Levei mais ou menos uma tarde para fazer tudo funcionar pela primeira vez. O obstáculo não foi a criptografia, mas a configuração do ambiente e a necessidade de decidir primeiro qual tabela vale a pena comprovar. Essa barreira existe de verdade, mas, em troca, você ganha algo muito concreto: a correção do resultado deixa de depender de em quem você confia. Comparado a soluções de feeds de preços como a Chainlink, que informam qual é o valor de algo neste momento, o SXT mostra qual critério foi usado e em que tabela o valor foi calculado. Comparado a painéis somente de leitura como o Dune, a diferença é que este último só pode fornecer uma captura de tela, enquanto o primeiro pode fornecer um recibo. É só uma questão de tempo até que uma IA tome uma decisão com base em uma captura de tela e algo dê errado. Houve também um efeito colateral que eu não tinha previsto no começo. Com as provas, cada decisão do agente pode ser reproduzida. Se algo der errado, dá para identificar qual consulta usou quais dados; responsabilizar alguém fica mais simples do que vasculhar logs, embora também custe mais. Por isso, não me importo muito com o quanto a história que contam sobre isso está em alta agora. O que me importa é: quando os agentes realmente começarem a chamar APIs e gastar dinheiro para comprar dados, quem vai cobrar pedágio nessa camada dos recibos? #sxt $SXT
