// Full article view
const ARTICLES = {
  1: {
    id: 1, cat: 'Arquitetura', tag: 'Ensaio', date: '14 abr 2026', time: 8,
    author: 'Felipe Castelini', authorRole: 'Fundador & Tech Lead',
    t: 'O fim da arquitetura de microsserviços (como conhecemos)',
    subtitle: 'Por que modulitos venceram a guerra silenciosamente.',
    body: [
      {
        type: 'lead',
        text: 'Em 2019, propor um monolito em uma entrevista técnica era quase uma heresia. Em 2026, as empresas que sobreviveram e cresceram têm, em sua maioria, algo em comum: elas voltaram atrás.'
      },
      {
        type: 'h2', text: 'O problema que ninguém queria admitir'
      },
      {
        type: 'p',
        text: 'A promessa dos microsserviços era sedutora: times autônomos, deploys independentes, escalabilidade granular. Na prática, o que vimos na maioria dos projetos foram 40 repositórios, 40 pipelines de CI/CD, 40 configurações de observabilidade, e um engenheiro de plantão que não conseguia rastrear uma transação sem abrir seis dashboards ao mesmo tempo.'
      },
      {
        type: 'p',
        text: 'O custo operacional de manter microsserviços raramente aparece no pitch inicial. Aparece na conta de cloud no terceiro mês. Aparece no onboarding de um novo desenvolvedor que leva três semanas para entender como o ambiente local funciona. Aparece no incidente de produção onde o root cause estava na latência de rede entre dois serviços que, na teoria, não deveriam se comunicar diretamente.'
      },
      {
        type: 'blockquote',
        text: 'O problema não era a arquitetura de microsserviços em si. Era que aplicamos uma solução de escala Netflix em problemas de uma startup com 12 engenheiros.'
      },
      {
        type: 'h2', text: 'O que é um modulito, afinal'
      },
      {
        type: 'p',
        text: 'Um monolito modularizado — o que a comunidade começou a chamar de "modulito" — não é um retrocesso. É a aplicação honesta do princípio de coesão: código que muda junto, fica junto. A diferença em relação ao monolito clássico está na disciplina de fronteiras internas. Cada módulo tem sua própria camada de domínio, seus próprios repositórios, seu próprio schema de banco de dados — mas todos correm no mesmo processo.'
      },
      {
        type: 'p',
        text: 'A migração para microsserviços genuína acontece quando há necessidade real de escalar um módulo de forma independente, quando times diferentes operam em ritmos muito distintos, ou quando há requisitos de isolamento de dados que o processo único não consegue garantir. Não antes.'
      },
      {
        type: 'h2', text: 'O que fizemos com os nossos clientes'
      },
      {
        type: 'p',
        text: 'Em três projetos nos últimos 18 meses, migramos arquiteturas de 30 a 60 microsserviços de volta para um modulito bem estruturado. Em todos os casos, o tempo médio de deploy caiu mais de 60%, o número de incidentes de produção relacionados a comunicação inter-serviço caiu para zero, e o onboarding de novos engenheiros foi reduzido de semanas para dias. Nenhum cliente precisou abrir mão de escalabilidade — eles ganharam previsibilidade.'
      },
      {
        type: 'p',
        text: 'A lição não é que microsserviços são errados. É que a maioria das empresas não tem a maturidade operacional, o tamanho de time ou a necessidade real que justifica o overhead. Quando esses três elementos existem, a arquitetura distribuída faz todo sentido. Enquanto isso, um modulito com fronteiras claras vai entregar mais, mais rápido, com menos dor.'
      },
    ]
  },

  2: {
    id: 2, cat: 'IA', tag: 'Pesquisa', date: '02 abr 2026', time: 44,
    author: 'Equipe Atom Forge', authorRole: 'Pesquisa',
    t: 'Estado da IA aplicada no Brasil — 2026',
    subtitle: 'Relatório anual com 240 empresas entrevistadas.',
    body: [
      {
        type: 'lead',
        text: 'Entrevistamos 240 empresas brasileiras entre janeiro e março de 2026 sobre adoção, maturidade e ROI de iniciativas de inteligência artificial em produção. A amostra cobre desde startups de série A até empresas com mais de 10 mil funcionários, distribuídas por onze setores e sete estados. O que encontramos desafia narrativas populares em ambas as direções: o hype subestima o progresso real em alguns bolsões, e superestima dramaticamente a maturidade na maioria dos outros.'
      },
      {
        type: 'h2', text: 'Metodologia e escopo da pesquisa'
      },
      {
        type: 'p',
        text: 'A coleta de dados ocorreu em duas fases. Na primeira, entre janeiro e fevereiro, aplicamos um questionário estruturado com 87 perguntas para 240 empresas. As respostas foram fornecidas por CTOs, CPOs ou equivalentes diretos — não por equipes de marketing ou comunicação. Na segunda fase, entre fevereiro e março, conduzimos entrevistas em profundidade com 38 empresas selecionadas por representarem casos extremos: as com IA mais avançada em produção e as com os projetos mais problemáticos. Esses contrastes foram mais reveladores que qualquer média.'
      },
      {
        type: 'p',
        text: 'A distribuição da amostra por setor: fintechs e serviços financeiros (22%), varejo e e-commerce (18%), saúde e healthtechs (14%), logística e supply chain (11%), indústria e manufatura (9%), educação (8%), agronegócio (7%), telecom e mídia (5%), e outros (6%). Por porte: empresas com 1 a 50 funcionários (19%), 51 a 500 (38%), 501 a 5.000 (31%), acima de 5.000 (12%). A sub-representação de grandes empresas é intencional — elas têm recursos e equipes dedicadas à IA que distorceriam o quadro geral do mercado brasileiro.'
      },
      {
        type: 'p',
        text: 'Por região geográfica, São Paulo responde por 54% da amostra, seguida pelo Rio de Janeiro (14%), Minas Gerais (9%), Santa Catarina (7%), Paraná (6%), Pernambuco (5%), e outros estados (5%). Essa concentração reflete a realidade do ecossistema de tecnologia brasileiro — não é uma limitação metodológica, mas é um fato que deve ser ponderado ao aplicar as conclusões a contextos regionais específicos.'
      },
      {
        type: 'h2', text: 'O cenário geral: adoção alta, maturidade baixa'
      },
      {
        type: 'p',
        text: '78% das empresas entrevistadas declararam ter ao menos um projeto de IA em andamento. O número parece alto — e é. Para contextualizar: em nossa pesquisa equivalente de 2024, esse número era 51%. O crescimento de 27 pontos percentuais em dois anos é real, acelerado principalmente pela popularização dos modelos de linguagem grandes (LLMs) e pela democratização de APIs de IA via provedores de nuvem.'
      },
      {
        type: 'p',
        text: 'Mas quando aprofundamos a pergunta — "esse projeto está em produção, com usuários reais, gerando resultado mensurável?" — o número cai para 23%. A maioria dos projetos vive em ambientes de sandbox, em pilotos que nunca chegam ao ar, ou em dashboards que ninguém consulta além do time que os construiu. Esse gap entre "ter um projeto" e "ter IA em produção" é o fenômeno central desta pesquisa, e ele é consistente com o que observamos nas entrevistas em profundidade.'
      },
      {
        type: 'blockquote',
        text: '23% dos projetos de IA chegam à produção. Os outros 77% morrem em algum ponto entre o hackathon e o deploy.'
      },
      {
        type: 'p',
        text: 'Os motivos mais citados para a não-evolução de pilotos revelam um padrão claro: falta de dados estruturados em qualidade suficiente para treinar ou fine-tunar modelos (64%), ausência de governança clara sobre outputs do modelo e quem é responsável por eles (58%), resistência interna dos times que seriam impactados pela automação (47%), falta de capacidade técnica interna para manter o sistema após o lançamento (41%), e restrições de compliance e LGPD não antecipadas durante o piloto (39%). O problema técnico de construir o modelo raramente é o gargalo principal. O problema é organizacional, cultural e de dados.'
      },
      {
        type: 'p',
        text: 'Há um padrão narrativo que observamos em quase todas as empresas que ficaram presas no limbo dos pilotos eternos: o projeto nasceu como uma iniciativa isolada de um time técnico entusiasmado, sem sponsorship executivo claro, sem integração com os processos existentes, e sem definição prévia do que "sucesso em produção" significa em termos de negócio. Quando o piloto termina e chega a hora de decidir se vai ao ar, não há critério estabelecido para essa decisão — e na ausência de critério, a resposta padrão é "continuar testando", indefinidamente.'
      },
      {
        type: 'h2', text: 'Maturidade por setor: quem está à frente e por quê'
      },
      {
        type: 'p',
        text: 'A análise por setor revela disparidades que vão além do que as médias gerais indicam. Fintechs lideram com uma folga considerável: 41% das fintechs entrevistadas têm IA em produção com ROI mensurável, contra 23% da média geral. Isso não é surpreendente — o setor tem historicamente alta densidade de engenheiros, dados estruturados abundantes (transações financeiras são por natureza digitais e formatadas), e regulação que paradoxalmente exige rastreabilidade de decisões, o que força a criação da infraestrutura de governança que outros setores evitam.'
      },
      {
        type: 'p',
        text: 'Varejo e e-commerce aparecem em segundo lugar com 34%, mas com uma particularidade: quase 80% dos casos de sucesso se concentram em recomendação de produtos, precificação dinâmica e previsão de demanda — problemas que o setor resolve com IA há uma década, muito antes da nova onda de LLMs. Quando expandimos a análise para incluir as aplicações mais novas — geração de descrições de produto, atendimento conversacional, análise de reviews — a taxa de sucesso cai para 18%, praticamente igual à média geral.'
      },
      {
        type: 'p',
        text: 'Saúde e healthtechs apresentam o caso mais complexo da amostra: alto nível de sofisticação técnica nos projetos que chegam à produção (todos com rastreabilidade robusta, validação clínica documentada, controle de versão de modelos), mas taxa de adoção relativamente baixa de 19%. A explicação que ouvimos consistentemente nas entrevistas: o ciclo de validação em saúde é longo por boas razões — e os times que respeitam esse ciclo chegam mais tarde, mas chegam com mais solidez. Os que tentam pular etapas geralmente não chegam.'
      },
      {
        type: 'p',
        text: 'O setor mais surpreendente da pesquisa foi agronegócio: 29% das empresas do setor têm IA em produção, acima da média geral, com casos de uso concentrados em análise de imagens de satélite e drones para detecção de pragas e estresse hídrico, previsão de colheita, e otimização de rotas de maquinário. O setor tem um ativo que muitos outros não têm: dados históricos limpos, coletados de forma consistente ao longo de décadas por empresas que já tinham cultura de instrumentação agrícola. Onde os dados são bons, a IA funciona melhor.'
      },
      {
        type: 'p',
        text: 'Indústria e manufatura aparecem na última posição, com apenas 11% de projetos em produção com resultado mensurável. Os projetos existem — 71% das industriais entrevistadas têm pilotos em andamento — mas o gap entre piloto e produção é o maior de qualquer setor. Os obstáculos são específicos do contexto industrial: dados de sensores IoT que chegam em formatos inconsistentes, sistemas legados de automação industrial que não se integram facilmente com pipelines de dados modernos, e uma cultura de engenharia que exige muito mais evidência de confiabilidade antes de aceitar qualquer sistema autônomo em um ambiente de produção física. Esses são obstáculos legítimos, não excesso de cautela.'
      },
      {
        type: 'h2', text: 'Onde o ROI aparece — e onde definitivamente não aparece'
      },
      {
        type: 'p',
        text: 'Para as empresas com IA em produção, pedimos que descrevessem o ROI observado em termos quantitativos. 67% conseguiram fornecer números — o restante tinha resultados qualitativos ou projetos muito recentes para ter dados. Os casos com retorno financeiro mensurável mais citados formam um padrão consistente com o que a literatura internacional reporta, com algumas particularidades brasileiras.'
      },
      {
        type: 'p',
        text: 'Automação de triagem e análise de documentos foi o caso de uso com o maior número de relatos de sucesso: redução de 40–70% no tempo de análise manual, com os extremos aparecendo em setores com documentação altamente padronizada (contratos de seguro, laudos médicos de formato fixo, pedidos de crédito). O denominador comum dos casos mais bem-sucedidos é sempre o mesmo: os documentos tinham estrutura previsível e os outputs esperados eram bem-definidos. Quando tentamos aplicar o mesmo approach em documentos mais heterogêneos — correspondência jurídica livre, emails de suporte com contexto variável — o ROI cai significativamente.'
      },
      {
        type: 'p',
        text: 'Copilotos de atendimento ao cliente geraram resultados consistentes: redução de 30–50% no tempo médio de primeira resposta, redução de 20–40% no volume de tickets que chegam ao atendimento humano, e — dado menos esperado — aumento de 15–25% na satisfação do cliente em CSAT medido. O aumento de satisfação se explica pela velocidade de resposta fora do horário comercial, onde o atendimento humano é limitado. Mas há uma advertência importante nos dados: nas empresas onde o copiloto foi implementado sem um processo claro de escalação para humanos, a satisfação caiu. O usuário aceita interagir com IA se sabe que pode falar com um humano quando precisa.'
      },
      {
        type: 'blockquote',
        text: 'O usuário brasileiro aceita IA em atendimento. O que ele não aceita é não conseguir falar com um humano quando a IA não resolve.'
      },
      {
        type: 'p',
        text: 'Detecção de anomalias e fraude foi o terceiro caso de uso com ROI mais consistente: redução de 20–35% em falsos positivos de fraude, o que na prática significa menos clientes legítimos bloqueados — um impacto de receita direto em fintechs que perdem conversão quando o sistema é muito conservador. As empresas com os melhores resultados aqui são invariavelmente aquelas que tratam o modelo como parte de um sistema humano-máquina, com analistas de fraude revisando os casos de borda e re-treinando o modelo com os erros. Modelos de fraude deixados sem manutenção por mais de 90 dias degradam de forma mensurável.'
      },
      {
        type: 'p',
        text: 'Do outro lado, os projetos com pior track record são reveladores. Geração de conteúdo de marketing e descrições de produto aparecem com frequência frustrante: o output técnico é impecável, o conteúdo gerado é indistinguível do humano em qualidade bruta, mas o impacto em conversão raramente justifica o investimento quando comparado com simplesmente contratar um redator experiente no nicho. O problema não é a qualidade do texto — é que bom texto de produto exige conhecimento de domínio, histórico do cliente, e intuição sobre o que ressoa com aquela base específica. O modelo genérico, por mais poderoso que seja, não tem esse contexto.'
      },
      {
        type: 'p',
        text: '"Chatbots de FAQ" continuam sendo o projeto com o pior histórico de ROI da categoria. O problema é estrutural: a FAQ representa os casos que o usuário consegue resolver sozinho. O chatbot que responde FAQ bem ainda deixa o usuário ligar quando tem um problema real — e o problema real é exatamente o que cria insatisfação. Empresas que implementaram chatbots de FAQ sem investir igualmente em resolver os problemas que chegam ao atendimento humano registraram aumento, não redução, de escalações e de insatisfação. O chatbot virou o primeiro obstáculo entre o cliente e a solução, não um atalho para ela.'
      },
      {
        type: 'h2', text: 'Os projetos que nunca chegam ao ar: anatomia do fracasso'
      },
      {
        type: 'p',
        text: 'Para entender os 77% de projetos que não chegam à produção, realizamos entrevistas em profundidade com 22 empresas que tinham projetos parados. O que ouvimos desenha um padrão que se repete com variações superficiais: o projeto nasce certo e morre no meio.'
      },
      {
        type: 'p',
        text: 'A história típica começa com um hackathon interno, uma demo de produto impressionante, ou um engenheiro que construiu um protótipo nas horas livres. O entusiasmo inicial gera um projeto formal com equipe dedicada. O protótipo funciona maravilhosamente com dados de exemplo. A demo para a diretoria gera aprovação. O piloto começa. E aí a realidade dos dados reais aparece.'
      },
      {
        type: 'p',
        text: 'Os dados reais têm problemas que os dados de exemplo não têm: valores nulos em campos que o modelo assume como obrigatórios, formatos inconsistentes entre sistemas de origem diferentes, informações desatualizadas que ninguém limpou desde 2019, e casos de borda que nenhum engenheiro antecipou durante o design. O que levou uma semana para funcionar com dados limpos leva meses para funcionar com dados reais — e esse prazo raramente foi previsto.'
      },
      {
        type: 'p',
        text: 'Quando o projeto finalmente funciona com dados reais, em nível técnico aceitável, geralmente já passou do prazo original em 3x e do orçamento em 2x. O sponsor executivo que aprovou o projeto foi promovido ou mudou de empresa. O time de negócio que ia usar o sistema mudou suas prioridades. E o engenheiro que fez a demo original está trabalhando em outra coisa. O projeto fica em estado de "quase pronto" indefinidamente, sem energia suficiente para ir ao ar e sem justificativa clara para ser cancelado.'
      },
      {
        type: 'blockquote',
        text: 'O cemitério da IA corporativa não está cheio de ideias ruins. Está cheio de ideias boas que encontraram dados ruins.'
      },
      {
        type: 'p',
        text: 'O padrão contrário — os projetos que chegam ao ar — também tem uma anatomia consistente. Os projetos bem-sucedidos geralmente começam menores do que a versão completa que se quer construir, têm um "momento de verdade" muito bem definido (o ponto específico onde o modelo precisa ter bom desempenho para o negócio funcionar), e têm um dono claro que será cobrado pelos resultados em produção desde antes do início do desenvolvimento. A diferença entre um projeto que chega e um que não chega raramente é técnica — é de gestão de expectativas, de escopo inicial disciplinado, e de accountability.'
      },
      {
        type: 'h2', text: 'A questão dos dados: o gargalo que ninguém quer resolver'
      },
      {
        type: 'p',
        text: 'Dados são mencionados como gargalo por 64% das empresas — mas essa estatística esconde uma distinção importante que as entrevistas em profundidade revelaram: a maioria das empresas não tem falta de dados. Tem excesso de dados ruins. A diferença é fundamental para entender as soluções necessárias.'
      },
      {
        type: 'p',
        text: 'Empresas com mais de 10 anos de operação digital geralmente têm terabytes de dados históricos. O problema é que esses dados foram coletados para fins operacionais específicos, em sistemas que não foram projetados para análise, com inconsistências que se acumularam ao longo de anos de manutenção descuidada. Um banco tem 15 anos de dados de transações — mas o schema do banco de dados mudou seis vezes, o campo de "tipo de transação" usa quatro convenções diferentes dependendo de quando a linha foi inserida, e há três sistemas de origem que definem "saldo" de formas ligeiramente diferentes.'
      },
      {
        type: 'p',
        text: 'A solução que ouvimos mais frequentemente nas empresas bem-sucedidas não é "coletar mais dados" — é "fazer um data contract". Data contracts são acordos formais entre times produtores de dados e times consumidores, especificando formato, semântica, SLA de qualidade e proprietário de cada campo. Isso parece burocrático. Na prática, é o que separa as empresas que conseguem treinar modelos de forma confiável das que ficam preso em ciclos infinitos de limpeza de dados.'
      },
      {
        type: 'p',
        text: 'Entre as empresas que implementaram data contracts formais — apenas 18% da nossa amostra — o tempo médio de preparação de dados para um novo projeto de IA caiu de 4,2 meses para 6 semanas. Esse é o tipo de retorno de infraestrutura que não aparece em nenhum dashboard de produto, mas é o que viabiliza ou inviabiliza a velocidade de entrega de qualquer iniciativa de IA subsequente. O investimento em data contracts é upstream — os dividendos aparecem downstream, em cada projeto futuro.'
      },
      {
        type: 'p',
        text: 'Outro padrão que emerge dos dados: empresas que têm bons dados são, quase sem exceção, empresas que decidiram tratar dados como produto antes de precisar deles para IA. Isso aconteceu não porque os líderes eram visionários sobre IA — mas porque tinham necessidades analíticas de negócio que exigiam qualidade de dados: relatórios financeiros precisos, forecasting de estoque confiável, análise de cohort de clientes. A IA de 2026 está colhendo os frutos de decisões de arquitetura de dados tomadas em 2020, por vezes por razões completamente alheias à IA.'
      },
      {
        type: 'h2', text: 'LLMs em produção: o que está funcionando e o que não está'
      },
      {
        type: 'p',
        text: 'A partir de 2024, LLMs passaram a ser a tecnologia de IA mais citada em novos projetos. Em 2026, 69% dos projetos de IA iniciados nos últimos 18 meses usam algum LLM como componente central. Isso muda o perfil dos casos de uso, dos desafios técnicos, e das formas de falha que observamos na pesquisa.'
      },
      {
        type: 'p',
        text: 'Os casos de uso onde LLMs estão demonstrando ROI consistente em nossa amostra: extração estruturada de informações de documentos não-padronizados (contratos, laudos, emails comerciais), geração e sumarização de relatórios internos para consumo de executivos, copilotos de escrita para times de suporte e vendas, e classificação de intenção em volumes altos de texto não-estruturado. Em todos esses casos, o denominador comum é que o LLM está reduzindo o trabalho humano de baixo valor cognitivo — a leitura e categorização manual de volumes altos de texto — e liberando o profissional para o trabalho de alta cognição: a decisão, a negociação, o julgamento.'
      },
      {
        type: 'p',
        text: 'Os casos onde LLMs estão falhando consistentemente são igualmente instrutitvos. Aplicações que exigem cálculo numérico preciso e rastreável continuam problemáticas — LLMs calculam, mas o processo não é auditável da forma que sistemas financeiros exigem. Aplicações em tempo real com latência abaixo de 200ms encontram dificuldades com os modelos de última geração, que são poderosos mas lentos para inferências síncronas. E qualquer aplicação onde o LLM precisa de conhecimento atualizado sobre eventos recentes sem RAG (Retrieval-Augmented Generation) bem implementado vai produzir alucinações que podem ser desastrosas dependendo do contexto.'
      },
      {
        type: 'blockquote',
        text: 'O LLM não sabe o que não sabe — e vai responder com a mesma fluência quando tem certeza e quando está inventando. Essa é a propriedade mais perigosa dessas ferramentas em contextos de alta consequência.'
      },
      {
        type: 'p',
        text: 'RAG emergiu como a abordagem de facto para mitigar o problema de alucinações em aplicações de domínio específico. Em nossa amostra, 61% das empresas com LLMs em produção usam alguma forma de RAG. Mas a qualidade da implementação varia enormemente: desde sistemas sofisticados com chunking semântico, re-ranking de relevância e citação rastreável das fontes, até implementações básicas que simplesmente jogam documentos em um vector store sem curadoria. As segundas alucinam com menos frequência que um LLM puro, mas alucinam com mais confiança — o sistema "encontrou" um documento que "suporta" a resposta, mesmo que o documento não suporte nada disso. Isso é pior do que uma alucinação simples, porque é mais difícil de detectar.'
      },
      {
        type: 'p',
        text: 'Fine-tuning de LLMs para domínio específico aparece em apenas 12% dos projetos — muito menos do que esperávamos. O motivo principal citado pelas empresas: o custo e a complexidade do fine-tuning não se justificam para a maioria dos casos de uso, especialmente com modelos de base cada vez mais poderosos que respondem bem a prompts bem elaborados. O pêndulo parece ter ido de "todo caso de uso precisa de fine-tuning" para "só faça fine-tuning quando prompt engineering esgotou suas possibilidades". Isso é provavelmente a calibragem correta para 2026.'
      },
      {
        type: 'h2', text: 'Infraestrutura de IA: onde as empresas investem — e onde subinvestem'
      },
      {
        type: 'p',
        text: 'O stack de infraestrutura de IA das empresas da nossa amostra é dominado pelos grandes provedores de nuvem: 71% usam APIs de IA da AWS, Google Cloud ou Azure como componente principal. 19% usam provedores especializados em LLMs (OpenAI, Anthropic, Cohere, etc.) diretamente, sem intermediação de cloud provider. Apenas 10% têm modelos self-hosted de forma significativa — e mesmo nesse grupo, a maior parte mantém modelos menores (7B–13B parâmetros) para casos de uso de baixa complexidade, enquanto usa APIs externas para os casos que exigem mais capacidade.'
      },
      {
        type: 'p',
        text: 'A dependência de APIs externas é um ponto de tensão crescente. 48% das empresas entrevistadas expressaram preocupação com vendor lock-in em provedores de LLM. Mas apenas 23% têm uma estratégia concreta de mitigação — geralmente uma camada de abstração que permite trocar de modelo sem refatorar a aplicação. Os outros 77% reconhecem o risco mas não o endereçam, o que é uma posição razoavelmente defensável enquanto os custos de troca permanecem baixos e a portabilidade entre provedores é relativamente alta para os casos de uso mais comuns.'
      },
      {
        type: 'p',
        text: 'Onde as empresas subinvestem de forma consistente é em observabilidade de IA. Monitoramento de modelos em produção — tracking de drift, análise de falhas por categoria de input, alertas de degradação de qualidade — está presente em apenas 29% das empresas com IA em produção. A maioria monitora disponibilidade e latência (métricas de infraestrutura) mas não monitora qualidade (métricas de modelo). Isso é análogo a monitorar se o servidor está de pé, mas não se a aplicação está respondendo corretamente. O servidor pode estar perfeito enquanto o modelo está produzindo outputs degradados por semanas sem que ninguém perceba.'
      },
      {
        type: 'p',
        text: 'Feature stores aparecem em 31% das empresas com IA em produção, concentradas principalmente em fintechs e empresas de varejo com mais de 500 funcionários. O investimento é alto e o retorno é de longo prazo — empresas que têm feature store conseguem lançar novos modelos em semanas em vez de meses, porque as features calculadas e validadas para um modelo estão disponíveis para todos os outros. Mas para empresas com poucos modelos em produção, o custo de construir e manter uma feature store dificilmente se justifica. A regra de bolso que observamos: feature store faz sentido a partir de três ou quatro modelos em produção com features compartilhadas.'
      },
      {
        type: 'h2', text: 'Governança e compliance: o mercado está atrasado'
      },
      {
        type: 'p',
        text: 'Apenas 31% das empresas com IA em produção têm alguma política formal de auditoria de outputs. Em setores regulados — saúde, fintechs, seguradoras — esse número sobe para 52%, mas ainda deixa quase metade operando sem rastreabilidade adequada. O número mais preocupante: apenas 19% das empresas com IA em produção têm um processo documentado para o que fazer quando o modelo falha de forma significativa. O que acontece quando o sistema de triagem de crédito começa a rejeitar grupos demográficos desproporcionalmente? Quem decide desligar? Em que prazo? Com que evidência? Menos de uma em cinco empresas tem uma resposta para isso.'
      },
      {
        type: 'p',
        text: 'A LGPD está começando a criar pressão real, especialmente em casos onde modelos processam dados pessoais sensíveis sem log de decisão. Em 2025, três casos de enforcement envolvendo uso de IA com dados pessoais foram noticiados, e a ANPD (Autoridade Nacional de Proteção de Dados) publicou orientações específicas sobre decisões automatizadas que afetam indivíduos. O mercado ainda não internalizou completamente as implicações, mas a direção da regulação está clara. Empresas que implementarem governança de IA agora estarão cumprindo requisitos regulatórios que ainda estão sendo formalizados.'
      },
      {
        type: 'p',
        text: 'Os elementos de governança mais comuns entre as empresas da nossa amostra, em ordem de prevalência: logging de inputs e outputs (58%), definição de um responsável humano por cada sistema de IA (47%), processo de aprovação antes de mudanças em modelos em produção (38%), avaliação de viés antes do lançamento (31%), e auditoria periódica de outputs por time independente do time de desenvolvimento (22%). Nenhum desses números é impressionante em termos absolutos — mas a correlação entre o número de práticas de governança implementadas e a satisfação com os resultados em produção é uma das mais fortes de toda a pesquisa.'
      },
      {
        type: 'p',
        text: 'Em termos práticos, isso significa: empresas com quatro ou mais práticas de governança implementadas têm taxa de incidentes com IA em produção 60% menor do que as com menos de duas. Governança não é burocracia — é o que separa sistemas de IA que funcionam de sistemas de IA que um dia param de funcionar sem aviso e sem capacidade de diagnóstico.'
      },
      {
        type: 'h2', text: 'Estrutura organizacional: quem toma decisões de IA nas empresas'
      },
      {
        type: 'p',
        text: 'Uma das perguntas mais ricas da pesquisa foi sobre estrutura organizacional: quem é responsável pelas decisões de IA na empresa? As respostas revelam um mercado em transição, com múltiplos modelos coexistindo e nenhum claramente dominante.'
      },
      {
        type: 'p',
        text: 'Em 44% das empresas, as decisões de IA são tomadas pelo CTO ou equivalente, como parte das responsabilidades de tecnologia em geral. Em 28%, existe um papel dedicado — Chief AI Officer, Head of AI, ou VP of Machine Learning — com autoridade explícita sobre a estratégia de IA. Em 18%, as decisões são descentralizadas, com cada produto ou área de negócio tomando suas próprias decisões sobre IA dentro de guidelines amplas. Em 10%, não há clareza sobre quem decide — IA é "responsabilidade de todos", o que na prática significa que é responsabilidade de ninguém quando algo dá errado.'
      },
      {
        type: 'p',
        text: 'As empresas com melhor desempenho em IA — medido por taxa de projetos em produção, ROI declarado, e número de iniciativas com resultado mensurável — estão concentradas nos dois modelos estruturais mais opostos: CTOs com engajamento profundo em IA (que constroem opinião técnica própria e não delegam completamente para consultores) e empresas com um papel dedicado de liderança de IA com mandato claro. O modelo descentralizado produz resultados medianos consistentes. O modelo de "responsabilidade de todos" produz resultados ruins consistentes.'
      },
      {
        type: 'blockquote',
        text: 'IA como responsabilidade de todos é IA como prioridade de ninguém.'
      },
      {
        type: 'p',
        text: 'A tensão entre centralização e descentralização da IA é genuína e não tem resposta universal. Empresas grandes com múltiplos produtos precisam de algum nível de descentralização para não criar um gargalo central. Mas descentralização sem uma plataforma compartilhada, sem standards mínimos de governança, e sem um mecanismo de compartilhamento de aprendizados resulta em dezenas de times reinventando a mesma roda, cometendo os mesmos erros, e construindo soluções incompatíveis entre si. O modelo que observamos funcionar melhor em empresas de médio porte (200–2.000 funcionários) é uma plataforma central pequena que cuida de infraestrutura comum, mais times de produto com autonomia para construir sobre essa plataforma.'
      },
      {
        type: 'h2', text: 'Talentos: o gargalo que não se resolve com dinheiro'
      },
      {
        type: 'p',
        text: 'A escassez de talentos em IA é citada por 74% das empresas entrevistadas como um desafio relevante. Mas quando aprofundamos o que "escassez de talentos" significa na prática, a resposta é mais nuançada do que a narrativa de "faltam engenheiros de machine learning" sugere.'
      },
      {
        type: 'p',
        text: 'O perfil mais escasso, de acordo com as empresas da nossa amostra, não é o pesquisador de deep learning — é o engenheiro de ML que sabe construir sistemas de produção. A diferença é crucial: um pesquisador de ML constrói modelos que funcionam em notebooks. Um engenheiro de ML que sabe construir sistemas de produção constrói pipelines de dados confiáveis, APIs que escalam, infraestrutura de monitoramento, e processos de re-treinamento automatizado. O segundo perfil é raro porque exige competências de engenharia de software sólidas além das competências de ML — e os programas de formação tradicionais produzem muito mais do primeiro do que do segundo.'
      },
      {
        type: 'p',
        text: 'Uma tendência que emergiu claramente nas entrevistas: empresas que terceirizam a construção de seus projetos de IA para consultorias externas, sem desenvolver capacidade interna de manutenção, estão criando uma dependência estrutural que vai custar caro. O projeto vai ao ar, funciona, e depois de seis meses começa a degradar silenciosamente porque ninguém interno sabe como monitorar os sinais de degradação, muito menos como corrigi-los. A consultoria entregou o que foi contratada para entregar — o projeto ao ar. O que a empresa não comprou foi a capacidade de manter o projeto funcionando.'
      },
      {
        type: 'p',
        text: 'A solução que as empresas mais bem-sucedidas adotam não é contratar mais engenheiros de ML — é criar pares de trabalho entre consultores externos e engenheiros internos durante a construção, com transferência explícita de conhecimento como critério de aceite do projeto. É mais lento, mais caro no curto prazo, e mais valioso no longo prazo. A empresa não apenas recebe o sistema — ela recebe a capacidade de evoluí-lo.'
      },
      {
        type: 'p',
        text: 'Capacitação interna de perfis não-técnicos também aparece como investimento de alto retorno. 63% das empresas com IA em produção bem-sucedida investiram em alguma forma de treinamento de produto managers, analistas de negócio e líderes de área no básico de IA — não para que essas pessoas construam modelos, mas para que façam perguntas mais inteligentes sobre o que a IA pode e não pode fazer, e para que participem de forma mais efetiva das decisões sobre onde aplicá-la. O ROI desse investimento é difícil de quantificar, mas a correlação com projetos que chegam ao ar é consistente.'
      },
      {
        type: 'h2', text: 'Open source vs. provedores comerciais: a guerra que o mercado ainda não decidiu'
      },
      {
        type: 'p',
        text: 'A adoção de modelos open source aumentou significativamente entre 2024 e 2026. Em nossa amostra, 43% das empresas usam modelos open source em pelo menos um projeto — um aumento de 18 pontos percentuais em relação à pesquisa de 2024. Os principais drivers dessa adoção são a redução de custos (especialmente para workloads de alto volume), a privacidade de dados em casos de uso sensíveis, e a possibilidade de customização que os provedores comerciais não oferecem facilmente.'
      },
      {
        type: 'p',
        text: 'Mas o open source não é gratuito — é custo transferido de licenciamento para operação. As empresas que tiveram sucesso com modelos open source geralmente têm infra própria (ou equipe capaz de gerenciar GPU infrastructure em nuvem), expertise interna para quantização e otimização de inferência, e volume de requisições que justifique o investimento em self-hosting. Empresas que adotaram modelos open source sem essas condições acabaram gastando mais em operação do que gastariam com a API de um provedor comercial, com qualidade inferior de output e sem o suporte que o provedor oferece.'
      },
      {
        type: 'p',
        text: 'A segmentação que observamos no mercado é pragmática: provedores comerciais para casos de uso de alta complexidade e baixo volume onde a qualidade é crítica, open source para casos de uso de média complexidade e alto volume onde o custo marginal por inferência importa. Essa divisão é estável e provavelmente vai se aprofundar — os modelos comerciais continuam mais capazes nos extremos de complexidade, mas a diferença está diminuindo em casos de uso de média complexidade, onde os modelos open source de última geração são genuinamente competitivos.'
      },
      {
        type: 'h2', text: 'Perspectivas para 2027: o que as empresas antecipam'
      },
      {
        type: 'p',
        text: 'Encerramos cada entrevista pedindo que os participantes descrevessem os dois ou três desenvolvimentos que mais esperam — ou mais temem — em IA nos próximos 12 a 18 meses. As respostas formam um quadro de expectativas que é ao mesmo tempo otimista e ansioso.'
      },
      {
        type: 'p',
        text: 'A expectativa mais citada com otimismo (62%) é a maturidade de agentes de IA: sistemas que não apenas respondem a perguntas, mas executam sequências de ações complexas de forma autônoma, com supervisão humana mínima. A maioria das empresas vê o potencial — automação de workflows completos, assistentes que de fato fazem o trabalho em vez de apenas sugerir — mas reconhece que a infraestrutura de confiança necessária (logging de ações, reversibilidade, governança de permissões) ainda está nascendo. A expectativa é que 2027 seja o ano em que as primeiras implementações de agentes robustos em domínios específicos se tornem padrão de mercado.'
      },
      {
        type: 'p',
        text: 'A segunda expectativa mais citada com otimismo (54%) é a consolidação de plataformas de IA que reduzam a complexidade de colocar e manter modelos em produção. O gap entre o que funciona em notebook e o que funciona em produção confiável ainda é enorme, e as empresas estão genuinamente cansadas de construir a mesma infraestrutura repetidamente. Há espaço considerável para plataformas que abstraiam esse gap, e o mercado está disposto a pagar por isso.'
      },
      {
        type: 'p',
        text: 'Os maiores temores para 2027 são de natureza diferente. 58% citam regulação como principal fonte de incerteza — não necessariamente por serem contra regulação, mas pela incerteza sobre como as novas regras serão interpretadas e aplicadas, e pelo custo de retroadequar sistemas já em produção. 47% citam a velocidade de mudança dos modelos de base como problema: ciclos de atualização de seis a doze meses significam que sistemas construídos hoje podem precisar de refatoração significativa em menos de um ano, criando dívida técnica antes mesmo de amadurecer.'
      },
      {
        type: 'p',
        text: '39% das empresas expressam preocupação com o que podemos chamar de "fadiga de IA" no usuário final: a percepção crescente, especialmente entre usuários mais sofisticados, de que são rodeados por sistemas de IA que não funcionam tão bem quanto prometido. Essa percepção, se se cristalizar, pode criar resistência a adoção de sistemas genuinamente úteis. A narrativa importa — e o mercado acumulou uma quantidade considerável de promessas que não foram cumpridas.'
      },
      {
        type: 'h2', text: 'Recomendações para times de tecnologia'
      },
      {
        type: 'p',
        text: 'Com base nas 240 entrevistas e nas análises desta pesquisa, identificamos oito recomendações práticas para times de tecnologia que querem construir capacidade de IA sustentável — não apenas projetos isolados de sucesso.'
      },
      {
        type: 'p',
        text: 'Primeiro: invista em dados antes de investir em modelos. A qualidade dos dados é o teto de qualidade de qualquer sistema de IA. Dados contracts formais, pipelines de qualidade mensuráveis, e ownership claro por domínio de dado são investimentos que pagam dividendos em todos os projetos futuros. Modelos melhores sobre dados ruins ainda produzem resultados ruins.'
      },
      {
        type: 'p',
        text: 'Segundo: defina o que "sucesso em produção" significa antes de começar o desenvolvimento. Qual métrica de negócio vai melhorar, em quanto, em quanto tempo? Quem vai medir? Esse acordo deve existir antes do primeiro commit. Sem ele, o projeto nunca terá um critério claro para ir ao ar — e vai viver indefinidamente em piloto.'
      },
      {
        type: 'p',
        text: 'Terceiro: comece menor do que você quer chegar. O projeto que vai ao ar com escopo de 30% do sonho original e aprende com usuários reais é mais valioso do que o projeto que está 80% completo e nunca chegou à produção. Produção ensina coisas que nenhum piloto ensina.'
      },
      {
        type: 'p',
        text: 'Quarto: trate observabilidade de modelos como obrigatória desde o dia 1. Logging de inputs e outputs, alertas de degradação de qualidade, e processo documentado de resposta a incidentes devem ser construídos junto com o sistema, não adicionados depois. Depois raramente acontece.'
      },
      {
        type: 'p',
        text: 'Quinto: invista em transferência de conhecimento se trabalhar com consultores externos. O critério de aceite de qualquer projeto desenvolvido externamente deve incluir capacidade de manutenção interna demonstrada. Isso torna o projeto mais caro e mais lento — e é o investimento certo.'
      },
      {
        type: 'p',
        text: 'Sexto: construa governança de IA como processo, não como documento. Uma política de IA que existe apenas em PDF não governa nada. A governança real está nos processos de aprovação antes do lançamento, nos revisores de output, nas reuniões periódicas de auditoria, e nas pessoas com autoridade para pausar um sistema que está se comportando mal.'
      },
      {
        type: 'p',
        text: 'Sétimo: avalie viés antes de lançar, não depois de um incidente. Avaliação de viés não é compliance performático — é engenharia de qualidade. Sistemas que discriminam grupos demográficos de forma não-intencional existem porque ninguém olhou para os dados de treinamento com essa pergunta. Fazer essa pergunta cedo é sempre mais barato do que responder publicamente depois.'
      },
      {
        type: 'p',
        text: 'Oitavo: resista à pressão de automatizar completamente quando a automação parcial já entrega 80% do valor com 20% do risco. O sistema que propõe e o humano que decide é, em muitos contextos, melhor do que o sistema que decide sozinho — tanto em resultado quanto em aceite organizacional. Autonomia total pode ser o objetivo de longo prazo; ela raramente é o ponto de partida certo.'
      },
      {
        type: 'blockquote',
        text: 'A pergunta não é "o modelo é bom o suficiente para decidir sozinho?" A pergunta é "o modelo mais o humano tomam decisões melhores do que o humano sozinho?" Se a resposta for sim, você tem um produto. Se a resposta for não, você tem um protótipo interessante.'
      },
      {
        type: 'h2', text: 'Metodologia detalhada'
      },
      {
        type: 'p',
        text: 'Esta seção descreve a metodologia completa para leitores interessados na validade e nas limitações da pesquisa. O questionário principal foi desenvolvido entre outubro e dezembro de 2025, com revisão por um painel de cinco CTOs e três pesquisadores acadêmicos de áreas de ciência de computação e gestão de tecnologia. O questionário passou por três rodadas de testes de compreensão com empresas fora da amostra final antes da aplicação.'
      },
      {
        type: 'p',
        text: 'A seleção das 240 empresas foi por conveniência estratificada: identificamos universos de empresas por setor e porte a partir de bases de dados públicas (Receita Federal, LinkedIn Empresarial, base de patentes do INPI para empresas de tecnologia), e dentro de cada estrato selecionamos aleatoriamente candidatos. A taxa de resposta foi de 38% — considerada alta para pesquisas B2B desse tipo. O incentivo para participação foi acesso antecipado ao relatório completo.'
      },
      {
        type: 'p',
        text: 'As entrevistas em profundidade foram conduzidas por três membros da equipe Atom Forge com experiência em condução de pesquisa qualitativa. Cada entrevista durou entre 60 e 90 minutos e foi gravada e transcrita com consentimento do entrevistado. Citações diretas usadas neste relatório foram aprovadas pelos entrevistados antes da publicação. Os nomes de empresas e indivíduos foram omitidos por padrão; alguns participantes solicitaram ser identificados e tiveram esse pedido atendido conforme sinalizado no texto.'
      },
      {
        type: 'p',
        text: 'As limitações que devem ser consideradas ao interpretar os dados: a amostra sobrerrepresenta empresas com algum nível de consciência sobre IA (empresas que não sabem o que é machine learning dificilmente responderam o questionário), o que significa que os números de adoção são provavelmente mais altos do que a realidade do mercado brasileiro em geral. A concentração geográfica em São Paulo e Sul/Sudeste também limita a generalização para regiões com ecossistema de tecnologia menos desenvolvido. Finalmente, como toda pesquisa por auto-relato, os números de ROI são declarados pelas próprias empresas — não foram auditados de forma independente.'
      },
      {
        type: 'p',
        text: 'O relatório completo com os dados brutos, crosstabs por setor e porte, e a transcrição editada das entrevistas em profundidade está disponível para solicitação mediante assinatura de NDA e pagamento de taxa de acesso. Pesquisadores acadêmicos interessados em acesso aos dados brutos podem entrar em contato diretamente para negociação de uso não-comercial. A metodologia deste relatório e os dados agregados são de livre circulação — por favor, cite a fonte.'
      },
    ]
  },

  3: {
    id: 3, cat: 'Design', tag: 'Entrevista', date: '28 mar 2026', time: 22,
    author: 'Larissa Matos', authorRole: 'Product Designer',
    t: 'Design systems como infraestrutura, não biblioteca',
    subtitle: 'Tokens, governança e por que um design system precisa do mesmo rigor de uma API pública.',
    body: [
      {
        type: 'lead',
        text: 'A maioria dos design systems morre por abandono, não por decisão. Eles começam como um projeto de energia, viram referência para dois ou três squads, e depois ficam desatualizados enquanto os times seguem em frente. O problema quase sempre é de governança, não de design.'
      },
      {
        type: 'h2', text: 'A armadilha da biblioteca de componentes'
      },
      {
        type: 'p',
        text: 'Quando pensamos em design system como uma biblioteca — um conjunto de botões, inputs e cards que todo mundo usa — colocamos o foco na entrega inicial. "Quantos componentes temos?" vira a métrica de sucesso. Mas uma biblioteca sem contrato de versão, sem política de breaking changes, e sem ownership claro é apenas um Figma compartilhado que vai sair de sincronia com o código em menos de seis meses.'
      },
      {
        type: 'p',
        text: 'Quando tratamos o design system como infraestrutura — com o mesmo rigor que uma equipe de plataforma trata uma API interna — a conversa muda completamente. Passa a existir changelog. Passa a existir processo de deprecação. Passa a existir alguém que acorda cedo quando o sistema quebra em produção.'
      },
      {
        type: 'blockquote',
        text: 'Um design system sem SLA de manutenção não é infraestrutura. É uma dívida técnica com identidade visual.'
      },
      {
        type: 'h2', text: 'Tokens como contrato'
      },
      {
        type: 'p',
        text: 'Design tokens são o lugar onde a abstração certa acontece. Não é "botão primário" — é o contrato semântico entre o que o designer decidiu chamar de "ação primária" e o que o código vai renderizar como cor, espaçamento e tipografia em qualquer plataforma. Quando tokens são bem definidos, uma mudança de tema afeta tudo ao mesmo tempo, sem caça manual a hex codes espalhados por 200 arquivos.'
      },
      {
        type: 'p',
        text: 'Mas tokens mal definidos — ou tokens demais, sem hierarquia semântica — criam o mesmo problema que variáveis globais em código: qualquer mudança pode ter efeito colateral inesperado. Nos projetos que conduzimos, adotamos três camadas: primitivos (valores brutos como #E63946), semânticos (--color-action-primary) e de componente (--btn-primary-bg). Isso garante que mudanças intencionais se propagam, e as não-intencionais ficam localizadas.'
      },
      {
        type: 'h2', text: 'Quem é dono disso?'
      },
      {
        type: 'p',
        text: 'A pergunta de governance mais importante não é técnica — é política. Design systems vivem na fronteira entre design e engenharia, e essa fronteira é frequentemente um território de ninguém. Nas empresas onde vimos design systems sobreviver e prosperar, havia uma pessoa (ou um time pequeno) com autoridade e responsabilidade explícita sobre o sistema. Não era responsabilidade "de todo mundo" — que na prática é responsabilidade de ninguém.'
      },
    ]
  },

  4: {
    id: 4, cat: 'Fintech', tag: 'Case', date: '21 mar 2026', time: 12,
    author: 'Pedro Alves', authorRole: 'Software Engineer',
    t: 'Como replatformamos um core bancário em 9 meses',
    subtitle: 'Migração com zero downtime para uma malha de serviços em Go. Métricas reais, cliente sob NDA.',
    body: [
      {
        type: 'lead',
        text: 'Migrar o core de um banco digital em operação — com transações acontecendo 24 horas por dia, sem janela de manutenção, sem poder errar — é o tipo de projeto que deveria ser impossível de concluir em menos de dois anos. Fizemos em 9 meses. Este é o relato técnico honesto de como.'
      },
      {
        type: 'h2', text: 'O estado inicial'
      },
      {
        type: 'p',
        text: 'O sistema legado era um monolito Java de meados dos anos 2010, rodando em VMs gerenciadas pelo time de infraestrutura. Funcional, mas com alguns problemas sérios: tempo de deploy de 4 horas em média, cobertura de testes abaixo de 20%, e um schema de banco de dados com mais de 800 tabelas onde ninguém mais sabia exatamente o propósito de umas 200 delas. O time de engenharia vivia em modo reativo — qualquer mudança levava semanas e exigia aprovação de um arquiteto que conhecia o sistema de cor.'
      },
      {
        type: 'p',
        text: 'O objetivo não era reescrever tudo — era extrair os domínios de maior risco e maior taxa de mudança para serviços próprios em Go, mantendo o monolito legado como "sistema de record" para os domínios estáveis, até que cada um deles fosse migrado de forma incremental.'
      },
      {
        type: 'blockquote',
        text: 'A regra que não negociamos: em nenhum momento dois sistemas poderiam ser a fonte de verdade para o mesmo dado. Sempre havia um dono.'
      },
      {
        type: 'h2', text: 'A estratégia: Strangler Fig em produção real'
      },
      {
        type: 'p',
        text: 'Usamos o padrão Strangler Fig com uma camada de proxy reverso que roteava tráfego dinamicamente. Cada domínio migrado passava por três fases: shadow mode (o novo serviço processava as mesmas requisições em paralelo, sem afetar o resultado real), canary com 1–5% do tráfego, e migração completa com rollback automático baseado em taxa de erro. Em nenhum momento o cliente final percebeu a transição.'
      },
      {
        type: 'p',
        text: 'O domínio mais crítico — liquidação de PIX — foi o último a migrar, intencionalmente. Passamos seis meses executando o novo serviço em shadow mode, comparando cada resultado com o sistema legado, antes de qualquer tráfego real. A diferença entre os dois outputs em qualquer transação era tratada como bug de severidade 1, independentemente do valor envolvido.'
      },
      {
        type: 'h2', text: 'Os números'
      },
      {
        type: 'p',
        text: 'Ao final dos 9 meses: tempo de deploy médio de 4 horas para 8 minutos. Cobertura de testes de 20% para 78%. Custo de infraestrutura reduzido em 34% (Go usa significativamente menos memória que JVM em cargas similares). Tempo médio de resolução de incidentes de 4 horas para 22 minutos, graças à observabilidade que construímos desde o primeiro serviço migrado. E zero downtime durante toda a migração.'
      },
    ]
  },

  5: {
    id: 5, cat: 'Cloud', tag: 'Artigo', date: '14 mar 2026', time: 6,
    author: 'Felipe Castelini', authorRole: 'Fundador & Tech Lead',
    t: 'FinOps não é sobre cortar — é sobre ver',
    subtitle: 'Como reduzimos 38% do custo de cloud de um cliente sem cortar nenhum workload.',
    body: [
      {
        type: 'lead',
        text: 'Quando um cliente nos procura com "queremos reduzir nosso custo de cloud", a primeira coisa que fazemos não é olhar para os recursos. É olhar para os dashboards que eles têm — ou não têm.'
      },
      {
        type: 'h2', text: 'O problema de visibilidade'
      },
      {
        type: 'p',
        text: 'Em 90% dos casos que vemos, a empresa não tem um problema de custo — tem um problema de visibilidade. A conta de cloud chega como um número total no fim do mês, distribuída por um time de finanças que não sabe o que é um NAT Gateway, para um time de engenharia que não sabe que NAT Gateways custam dinheiro. Ninguém está em uma posição de tomar boas decisões porque ninguém enxerga o que está gastando e por quê.'
      },
      {
        type: 'p',
        text: 'No projeto que descrevo aqui, a primeira fase foi puramente de instrumentação. Quatro semanas mapeando todos os recursos, aplicando tags de domínio e times, e construindo um dashboard que mostrava custo por feature, por ambiente, e por time. Ao final dessa fase, sem ter desligado nada, já sabíamos exatamente onde estava o dinheiro.'
      },
      {
        type: 'blockquote',
        text: 'O maior desperdício que encontramos? 23% do custo total em ambientes de staging que rodavam 24/7, sendo usados ativamente apenas 6 horas por dia.'
      },
      {
        type: 'h2', text: 'As mudanças que fizemos'
      },
      {
        type: 'p',
        text: 'Com visibilidade clara, as decisões foram simples. Ambientes de staging passaram a ter schedule de desligamento automático fora do horário comercial — economizamos 17% do total só com isso. Identificamos 8 instâncias de RDS com CPU médio abaixo de 3% que estavam superprovisionadas da época do lançamento — downsizing gerou mais 9%. Os outros 12% vieram de uma combinação de Reserved Instances nos workloads previsíveis e Spot no batch processing noturno.'
      },
      {
        type: 'p',
        text: 'Nenhuma feature foi cortada. Nenhum usuário sentiu diferença. O resultado foi 38% de redução na fatura mensal, e mais importante: um processo estabelecido para que o cliente continue fazendo isso de forma autônoma. FinOps não é um projeto — é uma prática. A instrumentação que construímos continua funcionando, e agora o time de engenharia olha para o custo toda semana, não só quando a conta chega.'
      },
    ]
  },

  6: {
    id: 6, cat: 'IA', tag: 'Ensaio', date: '07 mar 2026', time: 10,
    author: 'Felipe Castelini', authorRole: 'Fundador & Tech Lead',
    t: 'Agentes que ouvem antes de responder',
    subtitle: 'Copilotos de domínio exigem uma nova gramática de interação.',
    body: [
      {
        type: 'lead',
        text: 'O maior erro que vejo em produtos de IA conversacional não é técnico. É de design de interação: construir um agente que responde antes de entender. A diferença entre um copiloto útil e um que irrita está quase sempre nessa ordem de operações.'
      },
      {
        type: 'h2', text: 'O problema do agente ansioso'
      },
      {
        type: 'p',
        text: 'Modelos de linguagem são otimizados para gerar texto. Gerar texto é o que eles fazem melhor, e eles fazem isso com uma velocidade e fluência que cria a ilusão de que entenderam o que você precisava. Mas fluência não é compreensão. Um agente que produz uma resposta longa e bem escrita para a pergunta errada não está ajudando — está criando trabalho.'
      },
      {
        type: 'p',
        text: 'Em copilotos de domínio — sistemas que operam em contextos específicos, com usuários especialistas, tomando decisões com consequências reais — o custo de uma resposta errada é muito maior que o custo de uma pergunta a mais. O agente que pede confirmação antes de agir não é mais lento. É mais confiável.'
      },
      {
        type: 'blockquote',
        text: 'Dados, contexto e permissão, nessa ordem. Sem os três, o agente não deveria agir.'
      },
      {
        type: 'h2', text: 'A gramática que funciona'
      },
      {
        type: 'p',
        text: 'Em nossos projetos de agentes, estabelecemos três etapas obrigatórias antes de qualquer ação com efeito externo: coleta de dados suficientes para a tarefa (o agente pergunta o que não sabe, em vez de adivinhar), estabelecimento de contexto compartilhado (o agente reformula o que entendeu e aguarda confirmação), e permissão explícita para agir (o usuário aprova a ação, especialmente quando irreversível).'
      },
      {
        type: 'p',
        text: 'Isso pode parecer lento. Na prática, acelera. Usuários que confiam no agente delegam mais, com mais autonomia, porque sabem que não vão ser surpreendidos. A taxa de reversão de ações — o proxy mais honesto de satisfação com agentes — caiu de 18% para 3% nos sistemas onde implementamos esse protocolo.'
      },
      {
        type: 'h2', text: 'Onde isso fica difícil'
      },
      {
        type: 'p',
        text: 'A pressão dos produtos vai sempre na direção contrária: menos cliques, mais automação, mais "mágica". E há contextos onde isso faz sentido — tarefas de baixo risco, alta previsibilidade, usuários que já calibraram confiança com o sistema. O ponto é que a decisão de quando agir de forma autônoma precisa ser consciente, não um default de conveniência. O agente que age rápido demais não é mais inteligente — é apenas menos cuidadoso.'
      },
    ]
  },

  7: {
    id: 7, cat: 'Saúde', tag: 'Case', date: '28 fev 2026', time: 9,
    author: 'Pedro Alves', authorRole: 'Software Engineer',
    t: 'Triagem assistida por IA, auditada por médicos',
    subtitle: 'Protocolos versionados, decisões rastreáveis, LGPD desde o dia 1.',
    body: [
      {
        type: 'lead',
        text: 'Construir IA para saúde é diferente de construir IA para qualquer outro domínio. Não porque a tecnologia seja mais difícil — mas porque as consequências de errar são diferentes. Este case descreve como estruturamos um sistema de triagem assistida que está em uso hoje, com todas as salvaguardas que isso exige.'
      },
      {
        type: 'h2', text: 'O problema da triagem em escala'
      },
      {
        type: 'p',
        text: 'O cliente opera uma rede de clínicas com volume alto de atendimentos por UBS conveniadas. O gargalo era a triagem inicial: uma etapa feita por técnicos de enfermagem que precisavam classificar a urgência de cada caso com base em um protocolo clínico de dezenas de páginas, frequentemente sob pressão de tempo e com acesso inconsistente ao histórico do paciente. O resultado era variabilidade inaceitável: casos similares recebiam classificações diferentes dependendo do técnico e do turno.'
      },
      {
        type: 'p',
        text: 'O sistema que propusemos não substituía o técnico — ele fornecia uma recomendação fundamentada, com as referências do protocolo que embasavam aquela classificação, para que o técnico tomasse a decisão final com mais informação em menos tempo.'
      },
      {
        type: 'blockquote',
        text: 'A decisão clínica sempre ficou com o humano. O sistema propunha; o técnico dispunha. Sem exceção.'
      },
      {
        type: 'h2', text: 'Rastreabilidade desde o início'
      },
      {
        type: 'p',
        text: 'Cada recomendação gerada pelo sistema é armazenada com o conjunto completo de inputs que a produziram, a versão do modelo e do protocolo vigente no momento, e o ID do técnico que a validou ou reverteu. Isso não é apenas LGPD compliance — é o que permite ao time clínico auditar o sistema, identificar padrões de erro, e melhorar o protocolo ao longo do tempo.'
      },
      {
        type: 'p',
        text: 'O protocolo clínico em si é versionado como código: cada alteração tem autoria, data, e justificativa. Quando um médico responsável atualiza uma regra de triagem, o sistema registra a versão anterior e a nova, e todos os casos atendidos com cada versão são identificáveis. Isso parece óbvio — mas é raro.'
      },
      {
        type: 'h2', text: 'Resultados após 6 meses'
      },
      {
        type: 'p',
        text: 'Variabilidade de classificação entre técnicos reduziu 71%. Tempo médio de triagem caiu de 8,4 para 4,1 minutos. Taxa de revisão médica de classificações pós-triagem caiu 44%. Nenhum evento adverso relacionado ao sistema foi registrado. E o dado que mais importa para a equipe clínica: a satisfação dos próprios técnicos de enfermagem com a ferramenta é de 4,3/5 — eles sentem que têm suporte, não que estão sendo substituídos.'
      },
    ]
  },

  8: {
    id: 8, cat: 'Design', tag: 'Artigo', date: '21 fev 2026', time: 5,
    author: 'Larissa Matos', authorRole: 'Product Designer',
    t: 'Escrita de UI — a diferença entre "Salvar" e "Guardar"',
    subtitle: 'Quatro regras que aprendemos errando em produtos que rodam em escala nacional.',
    body: [
      {
        type: 'lead',
        text: 'Escrita de interface não é copywriting. É arquitetura de informação no nível da palavra. Cada label, cada mensagem de erro, cada placeholder é uma micro-decisão que, multiplicada por milhões de interações, define se o produto parece inteligente ou confuso.'
      },
      {
        type: 'h2', text: 'Regra 1: Use o verbo que descreve o que acontece, não o que o usuário faz'
      },
      {
        type: 'p',
        text: '"Salvar" e "Guardar" parecem sinônimos, mas em contextos digitais carregam expectativas diferentes. "Salvar" carrega a herança dos softwares de desktop — implica que sem essa ação os dados se perdem. Em sistemas com autosave, esse label cria ansiedade desnecessária. "Confirmar", "Concluir" ou "Aplicar" são mais honestos sobre o que a ação faz dentro do sistema. Nunca escolha um label por familiaridade; escolha pelo que ele comunica sobre o estado do sistema.'
      },
      {
        type: 'h2', text: 'Regra 2: Mensagens de erro são do sistema, não do usuário'
      },
      {
        type: 'p',
        text: '"Senha inválida" é uma acusação. "Não foi possível autenticar com essas credenciais" é uma descrição de estado. A diferença parece sutil, mas em pesquisas de usabilidade que conduzimos, mensagens que colocam a agência no sistema — em vez de culpar o usuário — reduzem consistentemente o abandono de fluxo. O sistema errou ao não conseguir processar; o usuário precisa de uma instrução para resolver, não de um julgamento.'
      },
      {
        type: 'h2', text: 'Regra 3: Tempo é contexto'
      },
      {
        type: 'p',
        text: '"Em instantes" e "Aguarde" não dizem nada. "Isso leva cerca de 30 segundos" gerencia expectativa. "Processando sua solicitação — você pode fechar essa janela" gerencia comportamento. Em qualquer estado de loading ou processamento, a pergunta que o usuário está fazendo é: "posso fazer outra coisa?" ou "preciso esperar?". Responda isso diretamente.'
      },
      {
        type: 'h2', text: 'Regra 4: Consistência bate criatividade'
      },
      {
        type: 'p',
        text: 'Um produto que usa "Cancelar" em metade das telas e "Voltar" na outra metade para a mesma ação cria carga cognitiva desnecessária. Não importa qual você escolhe — importa que você escolha um e mantenha. O mesmo vale para capitalização, uso de ponto final em labels, e forma de endereçar o usuário (você vs. tu, formal vs. informal). Essas decisões devem estar documentadas no design system. Se não estão, estão sendo reinventadas toda vez.'
      },
    ]
  },

  9: {
    id: 9, cat: 'Arquitetura', tag: 'Pesquisa', date: '14 fev 2026', time: 16,
    author: 'Equipe Atom Forge', authorRole: 'Pesquisa',
    t: 'Benchmark — latência de 12 bancos digitais brasileiros',
    subtitle: 'P99 de APIs públicas medido por 30 dias. Os resultados surpreendem.',
    body: [
      {
        type: 'lead',
        text: 'Durante 30 dias, entre dezembro de 2025 e janeiro de 2026, medimos a latência de APIs públicas de 12 bancos digitais brasileiros. Usamos endpoints de consulta de saldo e extrato, os mais utilizados por integrações de terceiros. Os resultados revelam disparidades maiores do que esperávamos.'
      },
      {
        type: 'h2', text: 'Metodologia'
      },
      {
        type: 'p',
        text: 'Todas as medições foram feitas a partir de três regiões: São Paulo (onde a maioria tem infraestrutura principal), Fortaleza e Porto Alegre. Capturamos p50, p95 e p99 de latência, taxa de erro por período do dia, e degradação durante horários de pico (abertura do mercado, almoço, fechamento). Não identificamos os bancos pelo nome neste relatório — usamos identificadores de A a L — por razões óbvias de relacionamento comercial.'
      },
      {
        type: 'blockquote',
        text: 'O banco com melhor p99 teve 340ms. O pior, 4.200ms. Ambos são bancos digitais com mais de um milhão de clientes.'
      },
      {
        type: 'h2', text: 'O que os números revelam'
      },
      {
        type: 'p',
        text: 'A maior surpresa foi a correlação negativa entre tamanho do banco e qualidade de latência. Dois dos três melhores performers são bancos menores, lançados após 2020, com arquiteturas cloud-native desde o início. Os dois piores performers são bancos com mais de 5 anos de operação — e a degradação mais acentuada acontece exatamente nos horários de pico, o que sugere limites de capacidade, não de design.'
      },
      {
        type: 'p',
        text: 'A taxa de erro conta uma história diferente. Cinco bancos tiveram taxas de erro acima de 0,5% em pelo menos um período da medição — o que, para APIs financeiras que alimentam integrações de terceiros, é problemático. O banco E teve um episódio de 23 minutos com 100% de erro em um domingo à tarde, sem comunicação de incidente. Descobrimos apenas pelos dados.'
      },
      {
        type: 'h2', text: 'Implicações para quem integra'
      },
      {
        type: 'p',
        text: 'Para times que constroem sobre APIs bancárias — fintechs, ERPs, plataformas de gestão financeira — os dados apontam para três práticas obrigatórias: circuit breakers com fallback explícito para cada banco integrado (não assuma que a API vai responder), cache agressivo de dados que mudam pouco (saldo pode ser stale por alguns segundos sem dano perceptível ao usuário), e monitoramento independente de SLA por parceiro. A garantia do banco e a experiência real do seu usuário são coisas diferentes.'
      },
      {
        type: 'p',
        text: 'O relatório completo, com os dados brutos e a metodologia detalhada, está disponível mediante solicitação. Entramos em contato com seis dos doze bancos antes da publicação — três responderam, dois solicitaram ajustes metodológicos que implementamos, um pediu que não publicássemos os dados referentes a eles. Não atendemos o último pedido, mas garantimos que nenhum banco fosse identificado nominalmente.'
      },
    ]
  },
};

const catColors = {
  Arquitetura: '#2563eb', IA: '#7c3aed', Design: '#db2777',
  Fintech: '#059669', Cloud: '#0891b2', 'Saúde': '#dc2626',
};

function ArticleBanner({ cat, tag, txCat }) {
  const txC = txCat || ((c) => c);
  return (
    <div style={{
      width: '100%', height: 320,
      background: 'var(--bg-2)',
      borderRadius: 22,
      border: '1px solid var(--line)',
      marginBottom: 72,
      position: 'relative',
      overflow: 'hidden',
      display: 'flex', alignItems: 'flex-end',
    }}>
      <div className="tick-grid" style={{ opacity: 0.6 }} />
      <div style={{
        position: 'absolute', top: 0, right: 0,
        width: '55%', height: '100%',
        background: `radial-gradient(ellipse at 70% 50%, ${catColors[cat] || 'var(--crimson)'}22 0%, transparent 70%)`,
        pointerEvents: 'none',
      }} />
      <div style={{ position: 'relative', padding: '32px 36px', zIndex: 1 }}>
        <div style={{ fontFamily: 'var(--mono)', fontSize: 9, letterSpacing: '0.16em', textTransform: 'uppercase', opacity: 0.45, marginBottom: 12 }}>
          {tag} · {txC(cat)}
        </div>
        <div className="display" style={{
          fontSize: 'clamp(56px, 8vw, 120px)',
          lineHeight: 0.88,
          letterSpacing: '-0.04em',
          color: catColors[cat] || 'var(--crimson)',
          opacity: 0.18,
          userSelect: 'none',
        }}>
          {txC(cat)}
        </div>
      </div>
    </div>
  );
}

function PageInsightArticle({ setPage, articleId }) {
  const t = useT();
  const post = ARTICLES[articleId];

  const tagMap = { 'Ensaio': t('is.t.essay'), 'Pesquisa': t('is.t.research'), 'Entrevista': t('is.t.interview'), 'Case': t('is.t.case'), 'Artigo': t('is.t.article') };
  const catMap = { 'Arquitetura': t('is.c.arch'), 'IA': t('is.c.ia'), 'Saúde': t('is.c.health') };
  const roleMap = { 'Fundador & Tech Lead': t('is.r.founder'), 'Pesquisa': t('is.r.research'), 'Product Designer': t('is.r.designer'), 'Software Engineer': t('is.r.engineer') };
  const ptMonthKey = { 'jan': 'is.m.jan', 'fev': 'is.m.feb', 'mar': 'is.m.mar', 'abr': 'is.m.apr', 'mai': 'is.m.may', 'jun': 'is.m.jun', 'jul': 'is.m.jul', 'ago': 'is.m.aug', 'set': 'is.m.sep', 'out': 'is.m.oct', 'nov': 'is.m.nov', 'dez': 'is.m.dec' };
  const txDate = (d) => { const p = d.split(' '); return p.length >= 2 ? p[0] + ' ' + (ptMonthKey[p[1]] ? t(ptMonthKey[p[1]]) : p[1]) + (p[2] ? ' ' + p[2] : '') : d; };
  const txTag = (tag) => tagMap[tag] || tag;
  const txCat = (c) => catMap[c] || c;

  if (!post) {
    return (
      <section style={{ padding: '120px 0', textAlign: 'center' }}>
        <div className="shell">
          <div className="display" style={{ fontSize: 40, marginBottom: 16 }}>{t('ar.not_found')}</div>
          <button className="btn btn-primary" onClick={() => setPage('insights')}>{t('ar.back_insights')}</button>
        </div>
      </section>
    );
  }

  const related = Object.values(ARTICLES)
    .filter(a => a.id !== post.id && (a.cat === post.cat || a.author === post.author))
    .slice(0, 3);

  return (
    <>
      {/* Header */}
      <section style={{ padding: '80px 0 48px', position: 'relative', overflow: 'hidden' }}>
        <div className="tick-grid" />
        <div className="shell" style={{ position: 'relative' }}>
          <button
            onClick={() => setPage('insights')}
            style={{
              display: 'inline-flex', alignItems: 'center', gap: 8,
              fontSize: 13, fontFamily: 'var(--mono)', opacity: 0.6,
              background: 'none', border: 'none', cursor: 'pointer',
              color: 'var(--ink)', marginBottom: 32, padding: 0,
              textTransform: 'uppercase', letterSpacing: '0.1em',
            }}
          >
            {t('ar.back')}
          </button>

          <div style={{ display: 'flex', gap: 8, marginBottom: 24 }}>
            <Chip>{txTag(post.tag)}</Chip>
            <Chip>{txCat(post.cat)}</Chip>
          </div>

          <h1 className="display" style={{
            fontSize: 'clamp(36px, 6vw, 80px)',
            maxWidth: '18ch',
            lineHeight: 1.0,
            margin: '0 0 24px',
          }}>
            {post.t}
          </h1>
          <p style={{ fontSize: 19, opacity: 0.72, maxWidth: 640, lineHeight: 1.5, margin: '0 0 40px' }}>
            {post.subtitle}
          </p>

          <div style={{ display: 'flex', alignItems: 'center', gap: 12 }}>
            <div style={{
              width: 40, height: 40, borderRadius: '50%',
              background: 'var(--crimson)', display: 'flex', alignItems: 'center', justifyContent: 'center',
              fontFamily: 'var(--mono)', fontSize: 12, fontWeight: 700, color: '#fff', flexShrink: 0,
            }}>
              {post.author.split(' ').map(w => w[0]).slice(0, 2).join('')}
            </div>
            <div>
              <div style={{ fontSize: 15, fontWeight: 600 }}>{post.author}</div>
              <div style={{ fontSize: 11, opacity: 0.55, fontFamily: 'var(--mono)', textTransform: 'uppercase', letterSpacing: '0.08em' }}>
                {roleMap[post.authorRole] || post.authorRole} · {txDate(post.date)} · {post.time} {t('ar.read_min')}
              </div>
            </div>
          </div>
        </div>
      </section>

      {/* Banner — static, no GSAP, avoids multi-instance animation conflicts */}
      <section>
        <div className="shell">
          <ArticleBanner cat={post.cat} tag={txTag(post.tag)} txCat={txCat} />
        </div>
      </section>

      {/* Body */}
      <section>
        <div className="shell">
          <div style={{ maxWidth: 720, margin: '0 auto 96px' }}>
            {post.body.map((block, i) => {
              if (block.type === 'lead') return (
                <p key={i} style={{
                  fontSize: 21, lineHeight: 1.65, fontWeight: 400,
                  opacity: 0.9, marginBottom: 40,
                  borderLeft: '3px solid var(--crimson)',
                  paddingLeft: 24,
                }}>{block.text}</p>
              );
              if (block.type === 'h2') return (
                <h2 key={i} className="display" style={{
                  fontSize: 'clamp(24px, 3vw, 36px)',
                  margin: '56px 0 20px',
                  lineHeight: 1.1,
                }}>{block.text}</h2>
              );
              if (block.type === 'p') return (
                <p key={i} style={{
                  fontSize: 17, lineHeight: 1.75,
                  opacity: 0.82, marginBottom: 24,
                }}>{block.text}</p>
              );
              if (block.type === 'blockquote') return (
                <blockquote key={i} style={{
                  margin: '40px 0',
                  padding: '24px 32px',
                  background: 'var(--bg-2)',
                  borderLeft: '4px solid var(--crimson)',
                  borderRadius: '0 12px 12px 0',
                  fontSize: 19,
                  lineHeight: 1.6,
                  fontStyle: 'italic',
                  fontFamily: 'var(--display)',
                }}>{block.text}</blockquote>
              );
              return null;
            })}

            {/* CTA */}
            <div style={{
              marginTop: 64, paddingTop: 40,
              borderTop: '1px solid var(--line)',
              display: 'flex', gap: 16, alignItems: 'center', flexWrap: 'wrap',
            }}>
              <button
                className="btn btn-primary"
                onClick={() => setPage('contato')}
                style={{ fontSize: 14, padding: '14px 24px' }}
              >
                {t('ar.cta_btn')} <ArrowIcon />
              </button>
              <button
                onClick={() => setPage('insights')}
                className="btn btn-ghost"
                style={{ fontSize: 14 }}
              >
                {t('ar.cta_ghost')}
              </button>
            </div>
          </div>
        </div>
      </section>

      {/* Related — no Reveal wrappers, no useReveal(), InsightVisualByCat renders cleanly one-per-card */}
      {related.length > 0 && (
        <section className="section-pad" style={{ background: 'var(--bg-2)' }}>
          <div className="shell">
            <SectionHeader eyebrow={t('ar.rel_ey')} title={<>{t('ar.rel_h2a')} <em className="display-italic">{t('ar.rel_h2em')}</em></>} />
            <div className="grid grid-3" style={{ marginTop: 48 }}>
              {related.map((r) => (
                <article
                  key={r.id}
                  className="card-hover"
                  onClick={() => setPage('insight-' + r.id)}
                  style={{ cursor: 'pointer', display: 'flex', flexDirection: 'column' }}
                >
                  <div style={{
                    aspectRatio: '4 / 3', background: 'var(--bg)', borderRadius: 14,
                    marginBottom: 18, overflow: 'hidden', border: '1px solid var(--line)',
                    position: 'relative',
                  }}>
                    <InsightVisualByCat cat={r.cat} />
                  </div>
                  <div style={{ fontFamily: 'var(--mono)', fontSize: 11, textTransform: 'uppercase', letterSpacing: '0.12em', opacity: 0.55, marginBottom: 10 }}>
                    {txTag(r.tag)} · {txDate(r.date)}
                  </div>
                  <h3 className="display" style={{ fontSize: 20, margin: '0 0 8px', lineHeight: 1.15 }}>{r.t}</h3>
                  <div style={{ opacity: 0.65, fontSize: 13, fontFamily: 'var(--mono)', marginTop: 'auto', paddingTop: 12 }}>
                    {r.author}
                  </div>
                </article>
              ))}
            </div>
          </div>
        </section>
      )}
    </>
  );
}

Object.assign(window, { PageInsightArticle, ARTICLES });