Figma cortou 70% do tempo de alertas — memória sem controle vira risco

A Figma relata ter reduzido em cerca de 70% o tempo de resolução de alertas complexos com agentes que reúnem contexto, investigam registros e preparam correções. A empresa não entregou o processo inteiro à IA: restringiu ferramentas, separou tipos de memória e manteve mudanças de código sob revisão humana.

O padrão transferível não é o percentual, cuja metodologia pública é incompleta. É a divisão entre precedentes, orientação geral, conhecimento operacional e estado persistente, combinada a controles externos ao modelo para impedir que uma lembrança inadequada se transforme em regra ou autoridade.

O que o sistema da Figma realmente faz

O fluxo começa nos alertas do Panther, que chegam ao Slack e geram tickets no Asana. Uma camada de recuperação procura ocorrências semelhantes e o raciocínio registrado anteriormente pelos engenheiros; sobre ela, o Tines encaminha cada solicitação a agentes especializados, com ferramentas e autorizações próprias.

O agente de triagem pode consultar dados do Okta, eventos de endpoints, recursos no Wiz, respostas do Panther e discussões autorizadas no Slack. Investigações mais profundas são delegadas a um subagente que converte perguntas em SQL e consulta no Snowflake o data warehouse do Panther, alimentado por registros como AWS CloudTrail, Okta, GitHub, GCP e telemetria de endpoints.

No relato técnico da Figma, a empresa informa redução aproximada de 70% no tempo de resolução de alertas complexos e queda de 20% nos acionamentos de plantão. O mesmo sistema pode abrir pull requests, mas uma etapa determinística do workflow converte cada PR criado pelo agente em rascunho.

Esses resultados pertencem ao ambiente interno da Figma, que já contava com SIEM, automação, um data lake de segurança e configurações tratadas como código. Eles não demonstram que conectar um agente a registros dispersos produzirá o mesmo ganho em outra organização.

Precedente, política, procedimento e estado exigem fronteiras

A memória de casos reúne alertas históricos e o contexto deixado por engenheiros no Slack e no Asana. Ela responde ao que aconteceu em situações parecidas, mas não deve criar uma regra universal: um evento benigno em determinada conta, período ou ambiente pode ser suspeito em outro.

A memória de direcionamento contém orientações comportamentais carregadas no início de cada execução. A Figma permitiu que correções de engenheiros persistissem nessa camada, mas descobriu que salvar nela aprendizados específicos demais fazia precedentes pontuais alterarem o comportamento do agente em situações indevidas. Foi daí que surgiu a distinção explícita entre precedente e política.

A memória procedural registra conhecimento necessário para operar as fontes, como esquemas, campos e formas corretas de consultar tabelas. Ela evita redescobertas técnicas sem promover o desfecho de um incidente a norma geral.

Já PRs abertos, identificadores de investigações e etapas em andamento são estado persistente, armazenado pela Figma em registros apoiados por banco de dados. São fatos com chaves e status estáveis, não lembranças em linguagem natural que o modelo deve tentar reconstruir.

A permissão acompanha a consequência da ação

A arquitetura concede capacidade de leitura suficiente para investigar, mas não acesso ambiental irrestrito. O agente não pode percorrer canais inteiros do Slack: fora de mensagens diretas, uma thread só fica disponível quando o bot é marcado novamente na mensagem mais recente. A consulta ao Okta também recebe filtros determinísticos para impedir o processamento de informações sensíveis de funcionários.

Na escrita, o limite é mais rígido. O agente pode preparar mudanças em regras de detecção, listas de permissão, infraestrutura, Terraform, RBAC ou configurações de identidade, mas não pode fechar nem modificar PRs que não criou. Os próprios PRs nascem como rascunho porque o workflow assim determina, não porque o prompt pede que o modelo se lembre de solicitar revisão.

O caso também não sustenta a ideia de um agente sem autoridade operacional. O sistema consulta dados sensíveis e pode rebaixar automaticamente alguns alertas considerados benignos ou duplicados. A fronteira correta é mais precisa: há autonomia limitada para ações delimitadas e auditáveis, enquanto mudanças de código consequentes não chegam à produção sem intervenção humana.

Como transformar o caso em uma arquitetura reutilizável

Uma implementação menor pode preservar as mesmas fronteiras sem reproduzir todas as integrações da Figma. A recomendação arquitetural é manter o modelo como coordenador de ferramentas específicas e colocar memória, autorização e transições críticas em componentes com regras verificáveis.

1. Casos: armazene evidências, contexto, decisão humana, escopo e data. A recuperação pode considerar recência e semelhança, sem promover automaticamente um caso a regra.
2. Políticas: mantenha orientações gerais versionadas, com responsável, aprovação, histórico e possibilidade de reversão. Uma correção feita durante o plantão não deve ganhar alcance global por padrão.
3. Procedimentos: registre esquemas, consultas e instruções operacionais validadas. Associe origem e validade para que mudanças nas fontes não perpetuem conhecimento obsoleto.
4. Estado: grave etapas, responsáveis, artefatos e identificadores em armazenamento transacional. O modelo não deve decidir, por lembrança textual, qual investigação ou PR continua aberto.
5. Ferramentas: conceda operações específicas em vez de credenciais genéricas. Separe leitura, proposta e execução e registre argumentos, resultados e identidade solicitante.
6. Ações consequentes: imponha por código o estado de rascunho e a aprovação necessária para merge, implantação, alteração de acesso ou encerramento de casos ambíguos.

A configuração das ferramentas também precisa ficar fora das cópias individuais dos agentes. Centralizá-la como código reduz o risco de pequenas variações de prompt ou integração criarem permissões diferentes sem inventário, revisão ou trilha de auditoria.

O ganho de 70% não é um benchmark universal

O tempo até a resolução mede eficiência operacional, não a qualidade da decisão de segurança. Para avaliar um piloto, é preciso separar tempo de triagem e de resolução, acionamentos evitados, reclassificações incorretas, reversões de PR, escalonamentos e completude da cadeia de evidências.

A análise da B2B News Network observa que a Figma não publicou o tamanho da amostra, o período de medição, a distribuição da linha de base nem a definição de alerta “complexo”. Também não divulgou a taxa de rebaixamentos incorretos ou quantos incidentes graves podem ter sido classificados de maneira inadequada.

Há lacunas semelhantes na governança da memória: o material público não detalha como mapeamentos de esquema são validados e renovados, como memórias contraditórias são conciliadas nem como mudanças globais na orientação recebem aprovação. Portanto, o percentual confirma um resultado relatado pela Figma, mas não permite atribuir causalidade a um controle isolado nem projetar o mesmo efeito em outra empresa.

O humano continua no ponto de decisão

O agente assumiu a coleta de contexto, a investigação inicial e a preparação de remediações. O engenheiro de plantão passou a revisar a cadeia de evidências, confirmar ou corrigir a conclusão e decidir sobre situações que exigem julgamento.

Essa divisão explica por que memória sem controle vira risco. Precedentes ajudam a comparar, políticas delimitam o comportamento, procedimentos ensinam a operar e o estado registra o andamento; nenhum deles deve ampliar permissões por conta própria. É o plano de controle externo ao modelo que determina quais ações podem produzir consequências reais.

Leia também:

• Lambda toma US$ 1 bilhão para alugar GPUs à Microsoft — o risco está no prazo
• Patch Tuesday sem sustos: teste, priorize e atualize sem parar a operação
• Nvidia garante US$ 36 bilhões à nuvem — o risco não ficou com os bancos