A 22 de setembro, o Claude registou um aumento de erros em vários modelos. A atualização final do incidente publicada pela Anthropic indica que o período afetado decorreu entre as 00h50 e as 02h10 UTC, ou seja, 80 minutos. O incidente foi dado como resolvido às 02h35 UTC. Entre os componentes afetados estavam claude.ai, a API, o Code e o Cowork. O registo não diz que todos os pedidos falharam e não apresenta uma explicação pública da causa principal. Registo do incidente da Anthropic
Para uma empresa que utiliza IA num processo de trabalho, o restabelecimento do serviço resolve apenas parte do problema. Os pedidos de clientes podem continuar à espera. Alguém pode ter começado a tratar um caso manualmente enquanto uma tentativa automatizada continuava ativa. Um supervisor precisa de saber que trabalho pode ser retomado e qual deve ser inspecionado primeiro.
A indisponibilidade ocasional de um assistente é um incómodo quando ajuda alguém a ter ideias. Quando o mesmo serviço ajuda a classificar casos recebidos, redigir respostas e atualizar registos, a interrupção torna-se um problema operacional. A preparação útil é um pequeno plano de continuidade que os funcionários possam seguir sem acesso ao próprio serviço de IA.
Este guia usa o exemplo hipotético de um serviço de apoio ao cliente para mostrar como poderia funcionar esse plano. Os procedimentos são propostas a adaptar e ensaiar, não um teste realizado pela BIG CHANGE nem uma descrição dos clientes afetados por este incidente.
Escolha o serviço que consegue manter sem IA
Imagine-se um pequeno fornecedor de equipamento cujo assistente classifica as mensagens de apoio recebidas e prepara respostas com base em informação aprovada sobre os produtos. Os funcionários reveem as respostas antes de as enviar. A empresa depende do sistema para organizar a fila, embora as pessoas continuem a ser responsáveis pelas respostas.
Se o assistente deixar de responder, a primeira decisão do gestor é determinar o que o serviço de apoio ainda consegue prometer. Os funcionários podem continuar a confirmar a receção dos pedidos e a tratar casos com prazos iminentes, adiando explicações rotineiras sobre os produtos. Precisam de aceder às mensagens originais e ao material de referência aprovado fora do assistente. Caso contrário, «passem a tratar tudo manualmente» é uma instrução sem meios para a cumprir.
Escolha antecipadamente esse serviço reduzido. Identifique a pessoa que o pode ativar, o trabalho que deve ser suspenso e os funcionários que cobrirão as tarefas restantes. Defina uma hora para rever a situação, para que uma solução temporária não se prolongue pela tarde sem nova avaliação. Os avisos aos clientes devem explicar o atraso e indicar como obter ajuda urgente, com promessas que a equipa consiga cumprir.
As orientações de engenharia da Google sobre sobrecarga descrevem a prestação de funcionalidades reduzidas, a limitação do tráfego e a prioridade a pedidos importantes quando há recursos limitados. São técnicas estabelecidas de fiabilidade, não um diagnóstico deste incidente do Claude. Aplicadas a um serviço de apoio, sustentam uma redução deliberada do âmbito quando o processamento normal não pode continuar. Google SRE: Lidar com a sobrecarga
O serviço reduzido também precisa de um limite de capacidade. Não é possível dois funcionários assumirem silenciosamente a carga de trabalho de um sistema automatizado que normalmente trata muito mais pedidos. Registe o que conseguem tratar, o que terá de esperar e quando será preciso pedir ajuda adicional. Para os clientes, um prazo de resposta credível é mais útil do que uma confirmação automática que sugira que o serviço continua normal.
Mantenha os registos do trabalho fora da conversa
O serviço de apoio precisa de registos dos casos que consiga consultar enquanto o modelo estiver indisponível. Pode usar o sistema de apoio que já tem. O essencial é a empresa conseguir determinar o que aconteceu sem pedir ao assistente interrompido que reconstrua o processo.
Para cada caso, preserve o pedido original, a pessoa ou o processo responsável e a última ação confirmada. Um rascunho guardado não equivale a uma resposta enviada. Uma alteração proposta a um registo de cliente não equivale a uma alteração confirmada pelo sistema. Guarde provas que permitam distingui-las, com as mesmas restrições de acesso aplicáveis às informações subjacentes dos clientes.
Durante uma interrupção, separe o trabalho nestas categorias práticas:
- Pronto a iniciar: ainda não começou qualquer processamento ou ação externa.
- Parcialmente preparado: existe uma classificação ou um rascunho, mas o passo seguinte está por concluir.
- Conclusão confirmada: o sistema de destino regista a ação pretendida.
- Incerto: tentou-se uma ação, mas não há confirmação.
Atribua os casos incertos a alguém que possa inspecionar o sistema relevante antes de os retomar. Se o assistente estava a preparar uma resposta quando a ligação falhou, um novo rascunho pode ser inofensivo. Se uma ferramenta separada estava a enviar a resposta, repetir toda a tarefa pode enviá-la duas vezes. A distinção deve constar do registo do fluxo de trabalho.
A documentação da API da Anthropic diz que uma resposta em fluxo contínuo pode falhar depois de uma resposta HTTP 200 inicial, indicativa de sucesso. Ver aparecer o primeiro texto ou receber esse estado inicial não demonstra que a resposta completa chegou. A integração deve reconhecer quando a operação terminou e preservar o trabalho parcial como parcial. Documentação de erros da API do Claude
Limite as novas tentativas e atribua-lhes um responsável
Uma nova tentativa pode resolver uma falha temporária. Também pode prolongar a incerteza se cada camada repetir a mesma tarefa por iniciativa própria. Antes de acrescentar outro botão de repetição ou um ciclo automatizado, pergunte ao fornecedor do software se a biblioteca cliente já volta a tentar por si.
A Anthropic documenta duas novas tentativas automáticas por predefinição para falhas transitórias nos seus SDK oficiais, com atrasos crescentes e respeito por uma instrução retry-after quando existe. A documentação dos erros também distingue problemas temporários no servidor de falhas de autenticação, permissões e pedidos malformados. Não se deve presumir que repetir o mesmo pedido resolve todas as categorias. Comportamento de novas tentativas documentado para o Claude
No serviço de apoio, a regra operacional deve especificar quando param as tentativas automáticas e quem recebe o caso depois. Preserve o identificador do pedido para resolver problemas. Permita que os funcionários vejam se uma tarefa está à espera, a ser tentada novamente ou aguarda uma pessoa, para não lançarem, sem saber, tentativas concorrentes.
A AWS explica que uma ação pode ter sido bem-sucedida mesmo que a resposta nunca chegue. As suas APIs idempotentes usam um identificador explícito do pedido para reconhecer repetições e impedir efeitos secundários adicionais. O serviço destinatário tem de cumprir esse contrato; acrescentar apenas um número de processo interno não oferece essa proteção. AWS sobre como tornar seguras as novas tentativas
Pergunte especificamente sobre as ações executadas pelo seu fluxo de trabalho. Uma tentativa repetida pode criar outro pedido de assistência ou enviar outro e-mail? Se não houver prevenção de duplicados, o plano deve prever uma verificação do registo de destino antes de tentar de novo. Repetir a geração de texto e repetir um processo empresarial inteiro exigem decisões diferentes.
Um modelo de recurso precisa de uma função mais limitada
Um serviço de IA alternativo pode ajudar a manter o trabalho em andamento, mas uma segunda conta é apenas o início de uma solução de recurso. A alternativa precisa das instruções adequadas, de material de referência aprovado e de autorização para tratar os dados. Também precisa de capacidade quando a empresa recorre a ela.
Escolha uma tarefa de recurso delimitada antes de tentar substituir tudo. No nosso serviço de apoio hipotético, outro modelo poderia classificar mensagens rotineiras enquanto os funcionários tratam das respostas aos clientes. A equipa poderia avaliá-lo com casos representativos, incluindo nomes de produtos ambíguos e pedidos que têm de passar para uma pessoa. Uma resposta fluente, por si só, não demonstraria que seguiu as regras de apoio da empresa.
Decida antes do incidente que informações podem ser enviadas ao serviço alternativo. Os funcionários não devem improvisar copiando registos de clientes para contas pessoais. Verifique as condições de tratamento de dados e as regras de acesso da alternativa durante o processo de aquisição, juntamente com a qualidade e o preço das respostas.
A existência de nomes de modelos diferentes também não demonstra disponibilidade independente. O serviço de recurso pode continuar a depender do mesmo início de sessão, ligação à rede, armazenamento de documentos ou software de orquestração. Mapeie as dependências que a alternativa proposta realmente elimina. Isso pode revelar que uma fila manual com documentos de referência acessíveis oferece mais proteção útil do que outro modelo por trás da mesma ligação que falhou.
As alternativas exigem manutenção à medida que as instruções mudam e o conhecimento dos produtos fica desatualizado. Os funcionários precisam de praticar os procedimentos que raramente usam. Uma pequena empresa pode optar, com razão, por manter um serviço manual mais lento em vez de pagar para duplicar toda a operação. A decisão deve ter em conta o custo do atraso e os danos que uma resposta incorreta pode causar.
Retome o trabalho com uma fila revista
Quando o fornecedor anunciar o restabelecimento, teste uma pequena amostra do seu próprio fluxo de trabalho antes de retomar o processamento normal. Inclua um caso que exija a consulta de documentos e a atualização de registos de que a empresa precisa. Uma resposta bem-sucedida do modelo não demonstra que todos os sistemas ligados estão prontos.
Depois, analise o trabalho em espera. Retire os casos já tratados manualmente, inspecione as ações incertas e identifique pedidos cujas circunstâncias tenham mudado. Um cliente pode ter fornecido informações novas durante a interrupção. Redigir uma resposta a partir de uma versão anterior do caso pode criar um novo problema depois de terminada a falha técnica.
Liberte o trabalho restante em lotes controlados. Reserve capacidade para novos pedidos urgentes e acompanhe a redução da fila. Se a procura recebida consumir toda a capacidade de processamento disponível, o atraso persistirá mesmo que todas as novas tentativas sejam bem-sucedidas. A recuperação pode exigir pessoal adicional, uma redução temporária do serviço ou uma extensão honesta dos prazos de resposta.
Considere-se outro exemplo numérico, independente: chegam 24 casos por hora e o processamento para durante 30 minutos. Ficam 12 casos à espera. Se o serviço passar depois a tratar 36 por hora enquanto continuam a chegar 24 casos novos, demora uma hora a eliminar o atraso. São pressupostos ilustrativos, não medições do incidente do Claude.
As orientações da Google sobre objetivos de nível de serviço começam pelo resultado importante para os utilizadores e pelas dependências necessárias para o alcançar. Para este serviço, uma métrica útil poderia ser a proporção de casos urgentes que recebem uma resposta adequada dentro do prazo prometido. A disponibilidade do fornecedor é relevante, mas a empresa também precisa de saber se os clientes receberam o serviço. Google SRE: Implementar objetivos de nível de serviço
Registe a hora em que o serviço normal ao cliente foi retomado, o número de casos por resolver e quaisquer correções necessárias posteriormente. Estas métricas revelam trabalho de recuperação que a página de estado do fornecedor não consegue observar.
Ensaie uma interrupção antes de alargar a automatização
Um exercício de simulação curto pode revelar falhas de acesso ou de atribuição de responsabilidades sem perturbar os clientes. Use alguns casos de apoio fictícios e percorra esta sequência:
- Suponha que o modelo fica indisponível a meio da preparação de uma resposta. Pergunte quem ativa o serviço reduzido e onde os funcionários encontram o pedido original.
- Num caso, considere que a resposta foi enviada e confirmada; noutro, que houve uma tentativa de envio sem confirmação. Verifique se a equipa sabe em que sistema pode apurar o resultado.
- Suponha que o fornecedor já recuperou, mas continuam a chegar casos novos. Decida que trabalho será retomado primeiro e como os casos concluídos manualmente serão retirados da fila em atraso.
- Peça a alguém que não tenha criado o plano que explique o procedimento e identifique as permissões ou registos a que não tem acesso.
Registe o que o exercício não conseguiu esclarecer. As soluções podem ser modestas: acesso a uma fila existente, um controlo de pausa claro, uma confirmação guardada ou a designação de um responsável pela recuperação. Nenhuma garante um serviço ininterrupto. Cada uma pode ajudar a conter melhor uma interrupção sem renunciar aos benefícios da automatização.
Antes de atribuir outra responsabilidade operacional a um assistente, peça a um colega que demonstre como seria tratada durante uma interrupção. Se a resposta depender de o assistente indisponível se lembrar do que estava a fazer, ainda há trabalho a fazer no plano de continuidade.
