Cloud Security Alliance e Rubrik lançam Centro de Resiliência de IA, mas ainda faltam provas

A Cloud Security Alliance lançou um Centro de Excelência em Resiliência de IA com a Rubrik como sua primeira parceira fundadora, levando uma nova disputa de segurança ao google news. O centro surge no momento em que empresas concedem a agentes de IA acesso a dados, identidades, aplicações e fluxos de trabalho de produção. Seu desafio central não é publicar mais orientações. É provar que as organizações conseguem conter, investigar e reverter ações danosas de IA.

A parceria também cria uma tensão imediata. A Cloud Security Alliance, ou CSA, se apresenta como uma organização de segurança neutra em relação a fornecedores. A Rubrik vende produtos de proteção de dados, recuperação cibernética e operações de IA. Essa combinação pode conectar pesquisa independente à experiência operacional, mas também exige uma governança clara.

O anúncio integra uma corrida mais ampla pelo controle da IA empresarial. Fornecedores de segurança descrevem cada vez mais os agentes de IA como trabalhadores digitais privilegiados, e não como software comum. Reguladores e órgãos de padronização, por sua vez, se concentram em gestão de riscos, responsabilização, testes e supervisão humana. O novo centro precisa conectar essas duas conversas sem se transformar em um canal de marketing de produtos.

O que o Centro de Resiliência de IA realmente muda

O centro leva a resiliência de IA de uma alegação de produto para uma disciplina de segurança compartilhada, embora suas entregas práticas continuem sendo o fator decisivo.

O trabalho tradicional de segurança de IA costuma se concentrar no comportamento do modelo. As equipes testam se um modelo produz respostas inseguras, expõe informações sensíveis ou segue instruções maliciosas. Esses testes são importantes, mas cobrem apenas parte do problema operacional.

Um agente de IA pode chamar ferramentas, recuperar documentos, alterar registros, enviar mensagens e acionar fluxos de trabalho de infraestrutura. IA agêntica significa software que seleciona e executa ações para atingir um objetivo com intervenção humana limitada. Quando essas ações alcançam sistemas de produção, um erro do modelo se torna um incidente operacional.

O novo centro oferece à CSA um fórum dedicado para estudar essa transição. Seu nome anunciado enfatiza a resiliência, não apenas a prevenção. Resiliência significa manter operações críticas durante um incidente e restaurar sistemas confiáveis depois dele.

Essa distinção muda a pergunta de segurança. Controles preventivos perguntam se um agente deveria executar uma ação. Controles de resiliência perguntam o que acontece depois que uma ação insegura ultrapassa essas defesas.

Os investigadores conseguem reconstruir o raciocínio e as chamadas de ferramentas do agente? Conseguem identificar todos os recursos afetados por uma instrução incorreta? A organização consegue restaurar dados sem preservar um estado corrompido? Consegue revogar identidades antes que um agente repita a ação?

Essas perguntas abrangem várias equipes. Engenheiros de IA entendem o comportamento dos modelos, enquanto equipes de identidade controlam credenciais e permissões. Equipes de operações de segurança investigam incidentes. Equipes de proteção de dados administram cópias de recuperação, e responsáveis pelo negócio definem quais processos precisam ser retomados primeiro.

Um centro de excelência pode criar uma linguagem comum entre esses grupos. Também pode publicar métodos de teste reutilizáveis, arquiteturas de referência, cenários de incidentes e critérios de recuperação. Essas entregas dariam aos compradores algo mais útil do que outra coleção de princípios de alto nível.

A CSA já conduz iniciativas mais amplas de garantia de IA. Seu agentic control framework inclui o RiskRubric V2, uma metodologia anunciada para quantificar o risco de modelos de IA. A CSA afirmou em junho que o framework envolveria Deloitte Italy, PointGuardAI e Tumeryk.

O centro de resiliência pode complementar esse trabalho se testar consequências além do modelo. A pontuação de risco pode identificar capacidades perigosas, enquanto os testes de resiliência podem medir contenção e recuperação. As empresas precisam dos dois porque até mesmo um modelo bem avaliado opera dentro de sistemas falíveis de software, identidade e dados.

O anúncio ainda não define como o centro medirá o sucesso. Seu valor dependerá de artefatos publicados, regras de participação e testes repetíveis de forma independente. Uma parceira fundadora reconhecida pode fornecer expertise e financiamento, mas não pode substituir esses resultados.

Por que esta manchete do google news importa para líderes de segurança

Os agentes de IA estão pressionando as equipes de segurança porque combinam velocidade de máquina, acesso amplo e comportamentos que continuam difíceis de prever.

Pesquisas da CSA já descreveram problemas significativos de visibilidade em torno de agentes empresariais. Um anúncio de abril de 2026 afirmou que 82 por cento das empresas pesquisadas tinham agentes de IA desconhecidos em seus ambientes. Também afirmou que 65 por cento relataram um incidente relacionado a agentes durante o ano anterior.

Esses números vêm de pesquisa patrocinada pela CSA e devem ser interpretados considerando sua metodologia e amostra. Ainda assim, o problema subjacente é familiar. Funcionários podem conectar assistentes a aplicações empresariais mais rapidamente do que as equipes de segurança conseguem inventariar essas conexões.

Um estudo separado da CSA relatou que mais da metade das organizações pesquisadas enfrentou violações de escopo por agentes de IA. Uma violação de escopo ocorre quando um agente age além da tarefa, dos recursos ou das permissões previstos por seu operador. Essa categoria inclui comportamento acidental, não apenas atividade maliciosa.

O risco aumenta quando as organizações reutilizam credenciais humanas ou atribuem contas de serviço amplas. Um agente pode receber permissão para ler uma pasta de projeto, mas herdar acesso a um repositório inteiro. Um prompt comprometido ou um plano defeituoso pode então transformar acesso excessivo em um incidente.

É por isso que a resiliência se tornou distinta da segurança convencional de modelos. Um modelo pode passar em testes de avaliação e ainda participar de um fluxo de trabalho danoso. A falha pode vir de uma integração, um erro de autorização, dados desatualizados ou uma sequência inesperada de ações individualmente permitidas.

O AI risk framework do National Institute of Standards and Technology organiza o trabalho de risco em torno de governar, mapear, medir e gerenciar sistemas de IA. Ele oferece às organizações uma base útil, mas cada empresa ainda precisa traduzir essas funções em controles operacionais.

Por isso, líderes de segurança enfrentam uma resposta obrigatória. Eles precisam adicionar agentes de IA aos inventários de ativos, revisões de identidade, planos de incidentes e exercícios de continuidade de negócios. Esperar que o comportamento dos modelos se torne totalmente previsível não é uma estratégia viável.

Desenvolvedores enfrentam uma pressão relacionada. Descrições de ferramentas, limites de permissão, comportamento de repetição e etapas de aprovação agora têm consequências de segurança. Um bug aparentemente inofensivo de automação pode repetir ações destrutivas à velocidade de uma máquina.

Compradores empresariais também precisam de melhores critérios de avaliação. Um fornecedor pode afirmar que sua plataforma governa agentes, detecta comportamentos arriscados ou reverte erros. Os compradores precisam de definições testáveis para cada afirmação antes de comparar produtos.

O centro poderia oferecer às equipes de compras uma linguagem comum de testes. Poderia definir campos mínimos de registro, objetivos de recuperação, testes de permissão e requisitos de evidência. Esse trabalho tornaria mais fácil incluir a resiliência de IA em contratos e avaliações de segurança.

Também ajudaria trabalhadores do conhecimento a entender por que fluxos de produtividade comuns precisam de controles. Um assistente que resume documentos locais tem um perfil de risco diferente de um agente que edita código-fonte ou registros de clientes. As equipes precisam classificar essas diferenças antes de atribuir acesso.

Organizações que constroem uma base de conhecimento pesquisável devem preservar o contexto das fontes, as permissões e o histórico dos documentos. Esses registros se tornam importantes quando uma resposta gerada por IA influencia uma decisão de produção.

A manchete do google news é, portanto, mais do que um anúncio de associação. Ela sinaliza que recuperação, evidência e continuidade estão se tornando parte da governança de IA empresarial. A pressão recai sobre toda equipe que trata a segurança de agentes como uma extensão da filtragem de chatbots.

O principal conflito é expertise de fornecedor versus padrões neutros

A Rubrik oferece ao centro experiência prática em recuperação, mas a CSA precisa impedir que a arquitetura de um único fornecedor defina toda a categoria de resiliência.

A Rubrik começou como uma empresa de proteção de dados e expandiu sua posição em torno de resiliência cibernética e operações de IA. Seus produtos se concentram em proteger dados, monitorar riscos e recuperar sistemas após uma interrupção. Esse histórico se encaixa na missão operacional do centro.

A empresa também se aproximou da governança de agentes. A Rubrik afirma que seu Agent Cloud pode monitorar ações de agentes, aplicar proteções de política, preservar evidências de auditoria e ajudar a desfazer erros. Essas continuam sendo alegações do fornecedor até que clientes e pesquisadores independentes as validem em ambientes variados.

Os anúncios da Rubrik em 2026 mostram a amplitude de sua estratégia. Em junho, ela apresentou a autonomous recovery, que a empresa descreve como um sistema agêntico para recuperar aplicações em nuvem. O escopo declarado inclui dados, configurações de rede, identidades e configurações.

Esse limite de recuperação mais amplo é relevante. Restaurar um banco de dados limpo não repara um agente que alterou políticas de acesso, configurações de aplicações ou recursos em nuvem. Um plano de recuperação utilizável precisa compreender as dependências entre todos esses componentes.

A Rubrik também anunciou integrações em torno do Claude Code e de agentes do Google Cloud. Seus Google Cloud controls enfatizam a governança semântica, que aplica políticas com base no significado e na intenção de uma ação. Essa abordagem difere de regras que inspecionam apenas comandos fixos ou nomes de recursos.

A parceria, portanto, dá à CSA acesso a questões técnicas relevantes. A Rubrik pode contribuir com padrões de incidentes, arquitetura de recuperação e lições de implantações empresariais. Também pode ajudar a financiar pesquisas que uma organização sem fins lucrativos talvez tivesse dificuldade de conduzir de outra forma.

No entanto, parcerias fundadoras criam influência. Um patrocinador pode moldar a terminologia, as prioridades de pesquisa, os cenários de teste e as premissas sobre a pilha técnica necessária. Essa influência se torna problemática quando um padrão favorece discretamente capacidades que apenas o patrocinador vende.

A CSA precisa contrabalançar esse risco por meio de governança transparente. Os grupos de trabalho devem incluir compradores, pesquisadores, provedores de nuvem, especialistas em identidade, equipes de segurança de aplicações e fornecedores concorrentes de recuperação. As orientações preliminares devem passar por revisão pública antes de se tornarem uma prática recomendada.

O centro também deve separar contribuições de endossos. Uma arquitetura de referência pode reconhecer a implementação da Rubrik sem defini-la como padrão. As suítes de teste devem funcionar em várias plataformas e incluir implementações manuais ou abertas quando for viável.

Este é o principal antagonismo da história: expertise de fornecedor versus garantia neutra em relação a fornecedores. Não se trata da Rubrik contra um concorrente nomeado. A disputa mais profunda diz respeito a quem poderá definir as evidências de resiliência de IA.

Já existem abordagens concorrentes. Os provedores de nuvem podem incorporar controles em suas próprias plataformas de agentes. Fornecedores de identidade podem restringir credenciais e autorizações. Empresas de observabilidade podem rastrear o comportamento de agentes, enquanto fornecedores de backup podem recuperar dados afetados.

Plataformas de segurança como CrowdStrike, Palo Alto Networks, Microsoft e Google podem conectar a atividade de IA a uma detecção de ameaças mais ampla. Startups estão desenvolvendo controles especializados de runtime, defesas contra prompts, camadas de identidade e sistemas de autorização de agentes. Cada grupo vê um ponto de controle diferente como o centro do problema.

Nenhum ponto de controle isolado é suficiente. A prevenção pode falhar, e os logs podem não captar o contexto de negócios. Cópias de recuperação podem preservar alterações indesejadas se as equipes as capturarem após um incidente. Controles de identidade podem limitar o acesso sem detectar ações inseguras dentro de um escopo aprovado.

Um centro neutro deveria testar como essas camadas funcionam em conjunto. Não deveria presumir que as empresas comprarão uma única plataforma integrada. Muitas organizações operam com nuvens mistas, aplicações legadas e ferramentas de segurança de diversos fornecedores.

Essa exigência torna o papel da CSA importante. A organização pode reunir grupos que, de outro modo, não concordariam sobre terminologia ou métodos de teste. O papel fundador da Rubrik pode acelerar o esforço, desde que o trabalho resultante permaneça portátil e aberto a questionamentos.

A Resiliência de IA Exige Mais do que Backups e Barreiras de Proteção

O problema mais difícil é reconstruir e reverter uma cadeia de ações aparentemente válidas sem destruir o trabalho legítimo concluído ao mesmo tempo.

Considere um agente autorizado a atualizar infraestrutura em nuvem. Ele lê um documento de configuração desatualizado, conclui que um recurso de armazenamento não está em uso e inicia sua remoção. Cada chamada individual de API pode ser válida e devidamente autenticada.

Uma política preventiva pode não detectar o erro porque o agente permaneceu dentro das permissões atribuídas. O monitoramento pode registrar cada ação sem compreender que o objetivo subjacente estava errado. Um backup pode preservar os dados, mas não o estado da rede, da identidade e da aplicação ao redor deles.

A recuperação então se torna um problema de raciocínio. Os investigadores precisam determinar quando o plano falho começou, quais ações vieram desse plano e quais sistemas dependentes mudaram depois. Eles precisam distinguir essas mudanças do trabalho legítimo realizado por pessoas e outros agentes.

O mesmo desafio aparece em aplicações de negócios. Um agente pode mesclar registros de clientes, alterar metadados de contratos ou enviar notificações incorretas. Restaurar um banco de dados inteiro pode apagar transações válidas concluídas após o erro.

Uma estrutura de resiliência eficaz deve definir a menor unidade segura de reversão. Essa unidade pode ser um arquivo, um objeto de banco de dados, uma política de identidade, uma transação de aplicação ou um conjunto coordenado de recursos. O limite correto depende do fluxo de trabalho e de suas dependências.

A estrutura também precisa de históricos de eventos confiáveis. Os logs devem identificar o agente, o modelo, a instrução, as ferramentas, as credenciais, as aprovações, o contexto recuperado e as alterações resultantes. Prompts sensíveis e dados de negócios exigem proteção, portanto o registro ilimitado cria seus próprios riscos de privacidade e segurança.

A aprovação humana não pode resolver todos os casos. Exigir aprovação para cada ação elimina grande parte do valor de um agente e incentiva os usuários a aprovar solicitações mecanicamente. Pontos de verificação baseados em risco são mais práticos, mas dependem de uma classificação precisa.

Ações de alto risco podem incluir excluir dados, alterar permissões, enviar comunicações externas, executar código ou modificar registros financeiros. Ainda assim, ações inofensivas podem se tornar perigosas por repetição ou combinação. Dez alterações comuns podem produzir um resultado crítico que nenhuma regra isolada detecta.

Controles semânticos tentam reconhecer esse contexto. Eles avaliam o que uma ação aparentemente pretende realizar, e não apenas sua forma técnica. No entanto, a aplicação semântica frequentemente usa modelos de IA, introduzindo outro componente probabilístico no caminho de controle.

Essa circularidade merece atenção. As empresas usam IA para detectar comportamento inseguro de IA porque regras estáticas não conseguem interpretar todos os fluxos de trabalho. O modelo de monitoramento também pode interpretar mal a intenção, não detectar um ataque novo ou bloquear trabalho legítimo.

O planejamento de resiliência pressupõe que esses controles às vezes falharão. Ele exige evidências imutáveis, ambientes de recuperação isolados, mapeamento de dependências e procedimentos de restauração testados. Também exige que os responsáveis pelo negócio decidam quais resultados importam mais.

O centro deveria transformar essas ideias em exercícios mensuráveis. Um teste poderia conceder acesso excessivo a um agente, inserir contexto enganoso e medir se os controles detectam o comportamento resultante. Outro poderia corromper a configuração de uma aplicação e avaliar a completude da recuperação.

Os resultados devem incluir mais do que uma marca de aprovação ou reprovação. Medidas úteis incluem tempo até a detecção, recursos afetados, completude das evidências, precisão da reversão e tempo até a retomada do processo de negócios. Os testes também devem registrar quanta intervenção humana foi necessária.

A experiência da Rubrik em recuperação pode orientar esses cenários. Ainda assim, os cenários devem permanecer portáteis entre produtos. Caso contrário, eles medem a compatibilidade com uma plataforma em vez da resiliência organizacional.

Um programa maduro também testaria condições degradadas. Os logs podem estar incompletos, as credenciais comprometidas ou os administradores indisponíveis. Atacantes podem mirar sistemas de recuperação após reconhecerem que esses sistemas limitam sua capacidade de pressão.

É aqui que a resiliência de IA se encontra com práticas estabelecidas de recuperação cibernética. As organizações precisam de cópias limpas de recuperação, caminhos administrativos protegidos e papéis de incidente ensaiados. A IA acrescenta novos problemas de causalidade e atribuição, mas não elimina esses fundamentos.

O Que o Anúncio Ainda Não Comprova

Um centro nomeado e um parceiro fundador não comprovam que as empresas conseguem se recuperar de falhas consequentes de IA.

A primeira incerteza diz respeito às entregas. O anúncio estabelece uma organização, mas o valor público virá de pesquisas, ferramentas, benchmarks e orientações de implementação. Esses resultados precisam de datas, responsáveis e processos de revisão.

A segunda incerteza diz respeito à participação. Um centro dominado por fornecedores de segurança poderia ignorar responsáveis por aplicações, engenheiros de IA, auditores, seguradoras e trabalhadores afetados. Também poderia favorecer controles que geram novas compras de software em vez de mudanças no desenho dos fluxos de trabalho.

A terceira incerteza diz respeito à validação. Os fornecedores têm incentivos para descrever seus produtos como camadas completas de governança ou resiliência. Testes independentes devem examinar falsos positivos, incidentes não detectados, sobrecarga operacional e falhas de recuperação.

A quarta questão é o escopo. “Resiliência de IA” pode se referir à disponibilidade do modelo, resistência adversarial, continuidade de negócios, recuperação de dados, contenção de agentes ou prontidão organizacional. Um centro que cubra tudo corre o risco de produzir orientações amplas demais para serem implementadas.

A CSA deveria definir um limite inicial restrito. Ações de agentes em sistemas empresariais oferecem um ponto de partida prático porque conectam identidade, dados, aplicações e recuperação. A organização pode se expandir após demonstrar resultados úteis.

Seu trabalho também deve distinguir ataques maliciosos de erros comuns. A injeção de prompt pode levar um agente a seguir instruções hostis ocultas em conteúdo recuperado. Um funcionário autorizado também pode fornecer uma solicitação ambígua que desencadeia o mesmo resultado prejudicial.

Esses casos exigem controles preventivos diferentes, mas suas necessidades de recuperação se sobrepõem. Os investigadores precisam identificar os sistemas afetados, conter novas ações, preservar evidências e restaurar um estado confiável. Uma boa estrutura pode abordar essa camada operacional compartilhada.

O alinhamento regulatório apresenta outro desafio. A Lei de IA da União Europeia usa categorias de risco e obrigações vinculadas a funções e aplicações específicas. Organizações dos EUA frequentemente dependem de estruturas voluntárias, regras setoriais, contratos e exigências estaduais.

Uma estrutura global de resiliência não pode tratar a conformidade como uma única lista de verificação universal. Ela deveria mapear controles para exigências jurisdicionais, preservando ao mesmo tempo um núcleo técnico comum. Caso contrário, empresas multinacionais terão dificuldade para usá-la de forma consistente.

O centro deveria resistir a promessas numéricas sem respaldo. Os tempos de recuperação variam conforme o desenho da aplicação, o volume de dados, as dependências e o escopo do incidente. Uma demonstração de produto sob condições controladas não pode estabelecer um objetivo universal de recuperação.

Também deveria divulgar patrocínio e direitos de decisão. Os leitores precisam saber quem seleciona projetos, aprova publicações, detém propriedade intelectual e resolve divergências. Atas transparentes e listas de colaboradores fortaleceriam a confiança.

O projeto RiskRubric V2 oferece uma comparação inicial. A CSA afirma estar buscando uma abordagem baseada em evidências para o risco de modelos, com diversos parceiros nomeados. O centro de resiliência deveria demonstrar abertura semelhante ao estender a medição para ambientes operacionais ativos.

A visibilidade no Google News pode atrair atenção para o lançamento, mas atenção não é adoção. As equipes de segurança julgarão o projeto pela capacidade de suas orientações de resistirem ao contato com sistemas de produção, auditores, equipes de resposta a incidentes e revisões de compras.

O padrão crítico é a falseabilidade. Uma alegação de resiliência deveria especificar as condições nas quais falha. Os compradores deveriam conseguir reproduzir o teste, comparar produtos e entender quais riscos permanecem após a implementação.

Até que esses elementos apareçam, o centro representa uma direção crível, e não uma solução verificada. Essa distinção não diminui o lançamento. Ela identifica o trabalho necessário para que a parceria conquiste autoridade.

Três Sinais que Mostrarão se o Centro Importa

A próxima etapa deve ser julgada por resultados abertos, participação independente e evidências de exercícios reais de recuperação.

O primeiro sinal é um roteiro publicado com entregas concretas. A CSA deveria identificar seus modelos iniciais de ameaça, escopo de testes, líderes dos grupos de trabalho e datas-alvo de publicação. Uma declaração de missão ampla não pode orientar a implementação.

A entrega inicial mais sólida seria uma estrutura para incidentes e recuperação de agentes. Ela deveria definir as evidências exigidas, etapas de contenção, limites de reversão e critérios de restauração do negócio. Também deveria mapear responsabilidades entre equipes de IA, segurança, identidade, dados e aplicações.

Se a CSA publicar esse roteiro com um processo aberto de revisão, o lançamento ganhará credibilidade. Se o centro permanecer limitado a eventos e comentários promocionais, a importância do anúncio enfraquecerá.

O segundo sinal é a participação além da Rubrik. Fornecedores concorrentes, provedores de nuvem, empresas, pesquisadores e especialistas em interesse público deveriam ter papéis significativos. Seu envolvimento deveria incluir autoria e governança, não apenas logotipos de membros.

A participação diversa importa porque a resiliência de IA abrange sistemas incompatíveis. Um teste desenhado em torno da telemetria ou do modelo de recuperação de um fornecedor não representará a maioria dos ambientes empresariais. A participação multiplataforma força o grupo a definir evidências portáteis.

Esse sinal fortaleceria a neutralidade do centro. Em vez disso, uma estrutura fechada e liderada por patrocinadores sustentaria preocupações de que o centro promove principalmente o marketing da categoria.

O terceiro sinal é a publicação de exercícios e resultados reproduzíveis. A CSA deveria criar cenários que testem injeção de prompt, permissões excessivas, uso destrutivo de ferramentas, contexto corrompido e recuperação incompleta. Os testes deveriam divulgar pressupostos e limitações conhecidas.

Exercícios reais deveriam medir se as organizações conseguem identificar o agente responsável e rastrear suas ações. Deveriam testar se as equipes restauram recursos afetados sem apagar alterações não relacionadas. Também deveriam avaliar a rapidez com que as operações normais são retomadas.

Os resultados públicos não precisam expor informações de clientes. O centro pode usar ambientes sintéticos, padrões de incidentes anonimizados e conjuntos de dados padronizados. O importante é permitir que outras equipes reproduzam o método.

Os resultados também devem comparar estratégias em camadas. Um ambiente pode depender principalmente de barreiras preventivas. Outro pode combinar permissões limitadas, rastreamento detalhado, cópias de recuperação protegidas e escalonamento humano.

Essa comparação testaria a premissa central do centro. A resiliência deve reduzir as consequências da falha dos controles, e não apenas acrescentar outro filtro preventivo. Evidências que sustentem essa premissa influenciariam a arquitetura de segurança e as decisões de aquisição.

Esses sinais importam além de uma única parceria. O setor de cibersegurança está em uma corrida para controlar a camada de controle dos agentes de IA. Os fornecedores descrevem identidade, monitoramento em tempo de execução, proteção de dados e recuperação como a base essencial.

A CSA pode ajudar as empresas a evitar escolher entre essas alegações apenas com base em marketing. Ela pode definir como as camadas interagem e quais evidências os compradores devem solicitar. Esse papel se torna mais valioso à medida que os agentes obtêm acesso a fluxos de trabalho críticos.

O anúncio encontrou público por meio do google news porque combina uma organização de padrões reconhecida com uma empresa pública de cibersegurança. Sua importância duradoura dependerá de um trabalho mais lento e menos visível.

Os líderes de segurança devem acompanhar o primeiro roteiro técnico, a composição dos grupos de trabalho e a publicação de testes de recuperação reproduzíveis. Esses três sinais mostrarão se o centro se tornará uma infraestrutura compartilhada ou apenas mais um fórum patrocinado.

Desenvolvedores e compradores empresariais devem usar o período de espera de forma produtiva. Façam um inventário dos agentes, mapeiem suas credenciais, registrem a atividade das ferramentas e identifiquem quais ações não podem ser revertidas com segurança. Em seguida, testem um incidente, da detecção à recuperação do negócio.

Após esse exercício, façam uma pergunta direta: sua organização conseguiria explicar e desfazer as ações do agente sob pressão? Se a resposta continuar incerta, acompanhem a produção técnica do centro, não apenas seus anúncios. A próxima matéria relevante no google news deve conter evidências que uma equipe independente consiga reproduzir.