Como estamos presenciando, muitas empresas e suas equipes de negócio e tecnologia tende cada vez mais a atestar suas habilidades em seus projetos o que envolve uma questão fundamentalque é analise do negócio e consequentemente analise de dados, tradicionalmente isso poderia ser uma tarefa árdua contudo hoje em dia (escrevo esse artigo em 30 de julho de 2026), isso vem se tornando “divertido”, empolgante e cada vez mais fácil, contudo isso vem e vai gerar um impacto gigantesco que vai impactar muitas empresas e ao mesmo gerar uma grande oportunidade de negócio para aqueles que já entenderam os fundamentos. Esse artigo é principalmente para profissionais não técnicos, já aviso desde agora.
LLM, IA, Claude, Gemini qualquer inteligencia artificial atualmente não é o que você pensa:
Já vou começar dizendo, todas as soluções que utilizam alguma inteligência artificial que em 99% dos casos utiliza um LLM (Large Language Model – um sistema de IA treinado com enormes volumes de dados) é probabilístico e não determinístico, ou seja, ele tem chances de errar por mais caro que seja a IA que você paga e sem saber os fundamentos que vou descrever aqui, vai errar muito mais. E o problema não é só ele errar é que por você estar perguntando, você desconhece da resposta, logo ambos não sabem o que é determinístico, sacou?
Dados não são software, IA atualmente é uma faca de dois gumes, permite criar soluções criativas para problemas complexos e gera resultados errôneos e por isso faço essa comparação com programação (lógica). Mas antes de fazer essa analogia deixe me explicar os principais problemas das respostas imprecisas das LLMs:
- Dados com ambiguidade: eu nunca escutei tanto essa palavra “ambiguidade” como hoje em dia, isso por que nunca tivemos tantos dados sendo gerados no mundo e também no âmbito corporativo e devido a isso, existe muita similaridade entre os dados que justamente um dos algorítimos que o LLM utiliza para te fornecer a resposta, então como ele deve escolher o campo certo de dezenas, centenas a milhares de campos de diversas fontes da sua empresa? Por exemplo: ao questionar o numero de clientes ativos em uma empresa de e-commerce, o que define um cliente “ativo”? Qual janela histórica deve ser considerada, quais variáveis e parâmetros?
- Dados sem ambiguidade: você pode ter uma estrutura de informações bem definidas e corretas, pode estar presente em um bom catalogo de dados e devidamente “anotada”, mas, dado a vastidão do espaço de busca, sua IA simplesmente não a encontra. Busca é diferente de armazenamento, um dado pode estar perfeitamente armazenado e ainda assim não ser recuperado, quanto maior o repositório de dados, maior a chance de a informação correta ficar “escondida” entre resultados mais prováveis, porém menos precisos. Quem é AI Native Engineer (especialista na construção de sistemas de agentes de IA) sabe que temos metadados e catálogos que melhoram a navegabilidade, mas não eliminam o problema de seleção entre múltiplas possibilidades. Em IA, o problema não é só guardar dados é fazê-lo emergir do espaço de busca certo.
- Dados antigos, conhecimento ficou com funcionário, cade a documentação: Essa é classica, o famoso “quem nunca”, recebeu uma demanda e não sabe por onde começar ou precisa confirmar uma informação importante, olha no Confluence (plataforma de documentação muito utilizada entre as empresas), pergunta para outros colaboradores, olha histórico de conversa e nada. As fontes de dados, as definições de negócio e os esquemas mudam constantemente e informação no meio corporativo deveria ser tratado como um ativo valioso, como em grande parte não é as IA corporativas se tornam ineficazes, obsoletas e começam a retornar respostas ligeiramente incorretas (fora o custo gasto para ingerir, armazenar, treinar e responder informação incorreta).
Agora voltando ao por que iniciei dizendo que dados não são software, isso foi provocativo por obviamente existe dados no processo de desenvolvimento de software, mas os dados não são utilizados como no processo e no caso de uso de LLMs, software e dados de IA cumprem papéis diferentes no processo de criação de valor. O Software é como uma máquina construída com engrenagens precisas (quando bem projetado é claro), cada entrada percorre um caminho definido e produz um resultado determinístico. Há regras, estados e fluxos controlados, e isso permite previsibilidade, rastreabilidade e repetibilidade. Já os dados usados por modelos de IA se comportam mais como um campo de possibilidades do que como um mecanismo fechado: eles alimentam um sistema que aprende padrões e responde com base em probabilidade, não em instruções fixas.
Processo de criação de software é determinístico e LLMs são probabilísticas, entendeu a solução?
Agora vou falar uma gíria antiga eu acho “horas bolas” se o processo de software consegue me garantir respostas confiáveis por que não “mesclar” os processos, pois bem, bem vindo ao mundo de agentes de IA, agentes de IA têm uma relação direta com o desenvolvimento de software por que funcionam como uma camada de automação inteligente sobre o processo de construção, validação e execução de tarefas, além de elas se comunicarem, se julgam e validarem entre si. Em vez de depender apenas de instruções manuais e intervenções pontuais, eles conseguem orquestrar passos, consultar contexto, chamar ferramentas (consultar google, chamar uma API por exemplo), validar resultados e repetir ciclos até atingir um objetivo definido. Isso aproxima a IA do modo como o software é desenvolvido: com regras, etapas, entradas, saídas e critérios de sucesso bem estabelecidos.
O valor dos agentes de IA aparece justamente quando eles reduzem a variabilidade do processo. Em sistemas tradicionais, muito do trabalho técnico depende de decisões humanas dispersas, interpretações diferentes e execuções não padronizadas. Já um agente pode aplicar um mesmo fluxo de decisão, com o mesmo contexto e as mesmas ferramentas, de forma consistente. Nesse sentido, ele ajuda a transformar dados e operações em algo mais determinístico, não por que elimine a natureza probabilística do modelo, mas porque cria uma camada de governança, estrutura e repetição em cima dessa incerteza.
Assim, agentes de IA não substituem o desenvolvimento de software; eles o estendem. O software continua sendo o território de previsibilidade, da lógica explícita e dos resultados controlados. o agente entra como um executor orientado por objetivo, capaz de usar a inteligência probabilística do modelo para produzir ações mais estáveis, rastreáveis e alinhadas ao processo. em outras palavras, o agente não retorna o LLM determinístico, mas torna o fluxo de trabalho mais determinístico ao redor dele.
Qual a principal maneira de minimizarmos os erros de dados para agentes de IA:
- Ambiguidade de entidades: as bases de dados e as fontes de verdade reduzem o espaço de entidades plausíveis até que haja uma única resposta definitiva.
- Obsoletismo : processos de manutenção e validação impedem que tudo se torne obsoleto à medida que o negócio muda.
- Falha na recuperação: as habilidades garantem que o agente encontre e utilize a resposta de forma confiável e correta.
Uma imagem da Anthropic – Claude que representa bem os valores em camadas de resolução:
Os fundamentos de dados sendo a camada 01 é o mais importante para garantir a precisão dos agentes analíticos que reside em uma base de dados sólida, isso inclui os modelos de dados, transformações, testes e tabelas de um banco de dados, datalake ou data warehouse, juntamente com os metadados (informações resumidas que descrevem melhor o registro) que os descrevem. A camada de fundamento de dados visa principalmente á ambiguidade: se a receita, por exemplo resultar em um conjunto de dados governado em vez de quarenta candidatos plausíveis, o problema praticamente desaparece antes mesmo que o agente precise realizar a busca. É também onde reside a primeira defesa contra dados desatualizados, visto que o mesmo repositório que define os modelos canônicos (verdadeiros) é o local natural para garantir que eles permaneçam atualizados.
Vamos algumas práticas que particularmente funcionam bem:
- Criar conjuntos de dados canônicos: reduzir a quantidade de modelos e tabelas duplicadas, mantendo apenas fontes únicas de verdade, bem governadas e fáceis de localizar. A ideia é que o agente encontre uma única resposta correta para cada conceito, em vez de lidar com várias opções parecidas.
- Impor padrões: não basta definir governança, é preciso aplicá-la por ferramentas, validação contínua e exigência organizacional. Assim, mudanças que ignoram os padrões falham cedo e evitam a proliferação de alternativas inconsistentes.
- Armazenar artefatos em conjunto: manter modelagem, camada semântica, documentação e definições verdadeiras no mesmo repositório ajuda a preservar consistência. Isso permite que alterações sejam validadas em conjunto e que problemas sejam detectados antes de chegar à produção.
- Tratar metadados como um produto de primeira classe: descrições, linhagem, granularidade, métricas verídicas, ownership e regras de negócio precisam ser mantidos com o mesmo rigor do código. Metadados ricos tornam o ambiente mais legível para humanos e agentes, aumentando a chance de selecionar o dado certo.
Fontes da Verdade
Agora falando da camada 02, se os fundamentos são as origem de dados, as fontes da verdade são as superfícies de referência que os agentes de IA consultam para navegar nele.Essa camada reduz a ambiguidade entre conceito e entidade e transforma “quantos clientes ativos eu tenho”, como perguntado por um stakeholder, em uma entidade específica e governada em seu modelo de dados. Em ordem decrescente de confiança, aproximadamente:
- Camada semântica: concentra as definições oficiais de métricas e dimensões, garantindo que perguntas equivalentes retornem sempre o mesmo valor. O ponto principal é que o agente deve consultar essa camada primeiro, e a definição das métricas deve ser feita por humanos, já que automação total tende a preservar ambiguidades em vez de eliminá-las.
- Linhagem e grafo de transformação: quando a camada semântica não resolve a dúvida, a linhagem ajuda o agente a entender quais modelos alimentam determinado conceito, quais estão desatualizados e quais têm a mesma granularidade. Isso permite raciocinar sobre qual fonte governada usar na agregação.
- Corpus de consultas: embora o histórico de SQL (Linguagem de consulta) de dashboards e análises pareça muito útil, acessá-lo diretamente não traz grande ganho. O valor real está em transformar esse histórico em materiais curados, como documentos de referência e padrões reutilizáveis, em vez de tratá-lo como fonte primária de verdade.
- Contexto de negócios: o agente precisa entender o significado real das perguntas dentro da empresa, não apenas o texto literal. Um grafo de conhecimento com documentos, decisões, estrutura organizacional e registros internos ajuda a resolver ambiguidades e a fazer perguntas de esclarecimento quando necessário.
Agentes de dados funcionam melhor quando combinam definições formais, linhagem confiável, conhecimento curado e contexto de negócio.
Habilidades
Agora subindo mais um nível da camada para a 03, se as fontes da verdade são o conhecimento declarativo do agente de IA, então uma habilidade é o seu conhecimento procedimental, por exemplo: quais fontes consultar e em que ordem, como navegar por dados ambíguos e qual a aparência de uma análise finalizada. Em Claude Code, uma habilidade é uma pasta de Markdown que o agente lê sob demanda. Na Anthropic, as habilidades agregam enorme valor. Sem elas, a capacidade de Claude de responder com precisão a perguntas analíticas não ultrapassava 21% das avaliações (fontes no final do artigo). Com a adição de habilidades, esses números sobem consistentemente acima de 95% no geral e frequentemente ficam em torno de 99% em determinados domínios.
Algumas boas práticas:
Crie habilidades em pares: uma habilidade de conhecimento atua como um roteador de alto nível simplificado que permite o carregamento de detalhes adicionais do domínio sob demanda. Ela indica: “Tente primeiro a camada semântica, mas se não houver cobertura, aqui estão cerca de 30 arquivos de referência para este domínio, descrevendo as tabelas, colunas, junções e peculiaridades relevantes.” Esse roteador é, na prática, nossa resposta à falha de recuperação: em vez de deixar o agente pesquisar em um repositório com milhões de campos, ele restringe o espaço a algumas dezenas de arquivos selecionados antes mesmo de uma consulta ser escrita. A habilidade de runbook codifica o processo que um analista sênior seguiria: esclarecer a pergunta, encontrar as fontes (por meio da habilidade de conhecimento), executar a consulta e, em seguida, passar o resultado por subagentes de revisão adversária. Ela também inclui uma dúzia de padrões de análise reutilizáveis (curvas de retenção, decomposição de taxas, análise de funil) para que solicitações comuns não sejam reinventadas a cada vez.
Crie documentação de referência adequada: escrita para consulta por um profissional de Direito. Uma documentação de referência descreve tabelas (granularidade, escopo e exclusões), os mecanismos de captura de erros (por exemplo, “exclua domínios de e-mail gratuitos conhecidos, mas mantenha domínios personalizados como anthropic.com“) e gatilhos de roteamento explícitos (por exemplo, “SE a pergunta for sobre o ganho experimental… NÃO use para contagens brutas de eventos”) sem receitas prescritivas que se tornam obsoletas. Veja abaixo um modelo que usamos para criar a documentação de referência.
OBS: Acredite o NÃO em maiúsculo faz diferença.
Um exemplo de um markedown de habilidades de consulta de dados seguindo as boas práticas:
# Tabelas [Domínio]
## Referência Rápida
### Contexto de Negócio — [o que este domínio significa em termos simples]
### Granularidade da Entidade — [o que uma linha representa]
### Filtro de Higiene Padrão — [o filtro que todas as consultas neste domínio aplicam]
## Dimensões
- [Como as dimensões-chave são codificadas e como o mesmo conceito é nomeado
de forma diferente em todas as tabelas]
## Tabelas-Chave
### [nome_da_tabela]
- **Granularidade**: [...] · **Escopo/exclusões**: [...]
- **Uso**: [quando usar, quando NÃO usar, chaves de junção, filtros necessários]
[... uma breve seção por tabela governada ...]
## Armadilhas
- [Os modos de resposta incorreta sobre os quais um analista sênior o alertaria]
## Melhores Práticas / Padrões de Consulta Comuns
- [Opções padrão, cortes padrão, padrões trabalhados onde a forma exata da consulta
é a parte difícil]
## Referências Cruzadas
- [Domínio vizinho] documentos que possuem perguntas adjacentes]Por fim meu preferido da camada a validação.
Validação:
Um padrão comum que observamos é que as equipes de dados configuram ambientes analíticos complexos sem ter nenhum processo para entender a precisão de seus agentes analíticos. E os times de IA também, ou criam mas em excesso, sem compreensão ou pela metade, Uma forma de abordar essa lacuna é por meio de avaliações offline, que são simples pares de perguntas e respostas. Você pode pensar nas avaliações offline como testes offline para um modelo de aprendizado de máquina, pois elas não informam o desempenho dos seus agentes online, mas fornecem uma boa noção de se haverá alguma lacuna crítica. O que tenho lido é que existem dois tipos de avaliações offline. As avaliações baseadas em painéis são geradas automaticamente pelo Claude (e posteriormente validadas por humanos), abrangendo as perguntas mais comuns das partes interessadas. Já as avaliações de cauda longa consistem em fornecer ao Claude ou qualquer modelo LLM, o contexto de negócios (roteiros, documentação de tabelas) e solicitar que ele gere perguntas plausíveis para o restante do domínio. Além disso, coletamos continuamente informações sempre que uma parte interessada corrige o agente em uma conversa, pois essa correção é uma possível avaliação.
Já a validação online, seria a etapa final que consiste em garantir que o desempenho real do sistema online seja o mais preciso possível. Algumas das etapas que seguimos incluem:
- Análise de confronto: descobrimos que o uso de uma habilidade do Claude para desafiar agressivamente todas as premissas subjacentes a uma possível resposta final aumentou a precisão em 6% em nosso conjunto de avaliação, mas ao custo de 32% mais tokens e 72% mais latência (Conforme fontes citadas no final desse artigo).
- Monitoramento passivo: dois sinais de produção que devem ser rastreados continuamente são a proporção de consultas de agentes que são resolvidas pela camada semântica e a proporção de respostas que usam linguagem de correção (“essa é a tabela errada”, “você não está aplicando o filtro antifraude”). Ambos alimentam um painel de controle revisado semanalmente, juntamente com a taxa de aprovação offline.
- Agente de correções : a parte que fecha o ciclo. Um agente agendado verifica os canais das partes interessadas a cada poucas horas em busca de correções semelhantes, redige uma correção de uma linha para o documento de referência relevante e abre um PR (Pull Request) com a tag do proprietário do domínio. O processo de correção é propositalmente simples, editar um arquivo Markdown, mesclar, sincronizar automaticamente em todos os lugares para que o proprietário do domínio não gaste muito tempo com a tarefa. As mesmas correções são então incorporadas ao conjunto de avaliação offline.
Para encerrar um exemplo de markedown de um arquivo principal de habilidades de armazenamento da Anthropic utilizado pelo Claude, a estrutura real do arquivo, com detalhes internos substituídos por [marcadores entre colchetes], não deve ser copiado literalmente, serve apenas para mostrar os tipos de seções que consideramos importantes registrar:
---
name: [warehouse-skill]
version: [x.y.z]
description: "SE o usuário solicitar uma consulta ao data warehouse da [empresa]
sobre qualquer questão relacionada a [lista de domínios de negócio] — ENTÃO invoque esta skill. NÃO a invoque
para [tarefas de engenharia adjacentes] ou perguntas sem componente de data warehouse."
---
# Instruções da Skill [Warehouse]
## Descrição
A fonte única de verdade para consultas seguras e eficazes ao [warehouse].
Referenciada por outras skills [listadas] para orientação na execução de consultas.
Atue como um Analista de Dados, fornecendo insights estratégicos e recomendações
baseadas em dados, mas busque orientação ao longo do processo.
**Decisões fora do escopo**: [áreas de produto, etc.] → apresente apenas os dados,
afirme que "a decisão cabe à [equipe responsável]", NÃO assuma uma posição nem
crie correções de código.
## Execução de consultas
Prioridade:
1. **[Conexão gerenciada]** (se disponível): [ferramenta de consulta] / [ferramenta de esquema]
2. **[Alternativa via CLI]** (se instalada): [projeto padrão, projeto de fallback]
3. **Nenhuma das opções** — solicite a autenticação do usuário e interrompa a execução
---
# Camada Semântica (primeira etapa OBRIGATÓRIA)
A camada semântica governada é o **caminho padrão obrigatório** para qualquer
pergunta sobre dados — utiliza os mesmos números da [ferramenta de BI], com
joins, granularidade e filtros já incorporados. O SQL bruto, conforme a
documentação de referência abaixo, é a **alternativa (fallback)**, utilizada
apenas quando se constata que o caminho da camada semântica não atende à solicitação.
## Fluxo de trabalho obrigatório
1. **Carregar** — [como carregar a camada semântica em cada ambiente de execução, incluindo alternativas]
2. **Descobrir** — pesquisar métricas/dimensões por palavra-chave; **sempre verifique
os segmentos** (os filtros populacionais canônicos nomeados — cláusulas WHERE
criadas manualmente para eles são a principal causa de respostas incorretas)
3. **Compilar + executar** — criar a especificação → compilar para SQL → executar
4. **Alternativa (fallback)** — apenas se a descoberta não encontrar métrica relevante ou a compilação falhar
→ SQL bruto via `references/*.md` (PARTE 3 abaixo)
> **Não desista cedo demais.** NÃO recorra ao SQL bruto pelos seguintes motivos:
> - "[filtragem de data personalizada / coortes]" → [coberto pelas especificações de dimensão temporal]
> - "[precisa de um JOIN]" → [a camada de métricas já encapsula seus JOINs]
> - [mais 3 ou 4 desculpas já refutadas que os agentes usam para pular a camada semântica]
### Janelas de data e fuso horário — decida antes de consultar
- **Data de referência (as-of date) vs. últimos N dias**: [convenção para cada um]
- **"Semana/mês passado"** → a última semana/mês do calendário *completo*, não os últimos 7/30 dias
- **Fuso horário padrão**: [TZ]; [exceção para certos agrupamentos de relatórios]
- **Atraso na atualização (freshness lag)**: [algumas] tabelas demoram a consolidar — baseie-se em MAX(date), não em "ontem"
---
# PARTE 1: OBRIGATÓRIO (Leia primeiro em toda solicitação)
## 🚀 Fluxo de trabalho de início rápido
1. **Verifique primeiro se há sinais de alerta (red flags)**: [solicitações restritas/com dados pessoais (PII), domínios com acesso restrito,
pedidos de alto impacto que exigem validação extra]
2. **Fora do escopo — escale, não tente adivinhar**: [solicitações de acesso, solução de problemas de pipeline,
dashboards desatualizados, afirmações sobre causa raiz, recomendações de produto/preço]
→ redirecione para [a equipe responsável], não responda
3. **Esclareça a solicitação**: período, segmento, a decisão de negócios que ela embasa
4. **Verifique se já existem dashboards**: [catálogos de dashboards por domínio]
5. **Identifique a fonte de dados**: [mapa de navegação abaixo; preferir tabelas governadas/agregadas]
6. **Executar a análise**: [filtros obrigatórios + revisão crítica/adversária]
7. **Entregar insights**: apresentar a metodologia, diferenciar observações de interpretações
## 🏢 Contexto de Negócios
### Desambiguação de Entidades (PRECISA ESCLARECER)
- **"[Termo A]" pode significar**: [entidade 1] ou [entidade 2] — sempre esclarecer qual
- **"[Termo B]" pode significar**: [entidade 1] → [entidade 2] → [entidade 3] (cadeia um-para-muitos)
- **"Usuários"**: [qual identificador fornece contagens precisas e quais as inflam]
### Terminologia de Negócios
- [Nomes atuais de produtos vs. aliases obsoletos que ainda aparecem como valores
fixos na camada de dados — escrever com os novos nomes, filtrar pelos antigos]
- [Principais siglas internas]
- Cálculos da **métrica principal (headline metric)**: [mensal / janela padrão / indicador antecedente]
- **Termos desconhecidos — pesquisar em [documentos internos], não adivinhar**
### Requisitos de Integridade de Dados ⚠️
- **NUNCA**: inventar dados/colunas; fazer afirmações especulativas além do que os dados mostram
- **SEMPRE**: usar divisão segura; diferenciar observações ("os dados mostram X")
de interpretações ("isso sugere Y"); apontar limitações
---
# PARTE 2: COMO FAZER (Seguir durante a execução)
## 🔧 Guia de Execução Técnica
- [Ferramentas de conexão gerenciada e detalhes de invocação via CLI]
- **Proteção de PII (Informações de Identificação Pessoal)**: para dados restritos, retornar o SQL para que o usuário
o execute por conta própria — não retornar os resultados
## 📊 Guia de Melhores Práticas de Análise
1. Esclarecer a solicitação antes de consultar os dados
2. Mostrar o trabalho realizado (filtros, inclusões/exclusões, atualidade dos dados)
3. Esclarecer os denominadores
4. Considerar o viés da amostra
5. Conectar ao impacto no negócio
6. **Revisão crítica de SQL (OBRIGATÓRIA)** — acionar o subagente [sql-reviewer]
para cada consulta antes da resposta final; descobertas impeditivas devem ser corrigidas
e revisadas novamente; não fazer auto-certificação
7. **Relatar com procedência** — toda resposta termina com um rodapé:
> **Fonte:** [camada semântica | tabela governada | exploração de dados brutos] ion] ·
> **Confiança:** [nível] · **Revisado:** [revisor ✓, rodada N] ·
> **Atualização:** [data máxima nos dados] · **Proprietário:** [equipe responsável]
---
# PARTE 3: REFERÊNCIAS E RECURSOS DE DADOS
## 📚 Navegação da Base de Conhecimento
### [Domínio A] → `references/[domain_a].md`
- **Usar para**: [tipos de perguntas]
- **Tabelas principais**: [...]
- **Painéis**: `references/[domain_a]_dashboards.json`
### [Domínio B] → `references/[domain_b].md`
- **Usar para**: [...]
[... uma entrada por domínio de negócios — algumas dezenas no total ...]
## ⚠️ Guia de Solução de Problemas
### Quando Faltam Informações
- [tabelas ausentes / acesso negado / documentação desatualizada / valores de enumeração desconhecidos → o que fazer]
### Armadilhas na Nomenclatura de Campos
- Use `[campo_x_v2]` e NÃO `[campo_x]`
- [Duas tabelas com nomes semelhantes reportam a mesma métrica em diferentes níveis de granularidade — qual usar?]
- [Qual das duas fontes plausíveis é a canônica para a métrica principal?]
- [… mais uma dúzia de dicas valiosas…]No fim das contas, o que este artigo mostra é que análise de dados com IA não é sobre deixar o modelo “dar um chute melhor”. É sobre criar uma base bem governada, com contexto, métricas confiáveis, documentação viva e caminhos claros para o agente encontrar a resposta certa. Quando isso existe, a IA deixa de ser uma camada de risco e passa a ser uma camada de escala. É assim que a gente consegue sair do caos das perguntas repetitivas e abrir espaço para análises realmente estratégicas. Esse é o tipo de evolução que faz sentido para times de dados, para o negócio e para quem quer usar IA de forma séria, prática e sustentável.
Fontes:
- https://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude
- https://www.mckinsey.com/featured-insights/destaques/o-verdadeiro-valor-da-ia-no-desenvolvimento-de-software/pt
- https://scalalabz.com.br/blog/como-os-agentes-de-ia-estao-transformando-a-analise-de-dados/
- https://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude
