Quando o cérebro digital desliga
Esta semana, o Claude teve uma falha que afectou várias das suas superfícies principais.
A 16 de agosto, entre aproximadamente as 21:58 e as 22:34 UTC, alguns utilizadores não conseguiram autenticar-se no Claude.ai, no Claude Code e no Claude Cowork. O problema acabou por abranger também o Claude Console, a API do Claude e outros serviços associados. Durante esse período, houve pedidos que não terminavam, sessões que não carregavam e respostas que falhavam.
A própria página de estado da Anthropic registou o incidente como resolvido depois de cerca de 36 minutos. Nos dias anteriores, já tinham sido registadas outras ocorrências de degradação em diferentes componentes.
Para quem usa um chatbot ocasionalmente, uma interrupção de meia hora pode ser apenas uma inconveniência.
Para uma empresa que utiliza um LLM para classificar pedidos, responder a clientes, escrever código, extrair informação de documentos ou executar tarefas automáticas, o impacto pode ser muito maior.
Um agente pode ficar parado a meio de uma operação. Uma API pode devolver um timeout depois de já ter iniciado uma tarefa. Um workflow pode ficar bloqueado à espera de uma resposta que nunca chega. Um pedido pode ser repetido várias vezes e criar duplicações.
Quando o servidor de uma aplicação falha, já sabes que precisas de redundância. Quando o modelo que interpreta informação e toma decisões deixa de responder, a mesma regra deve aplicar-se.
A inteligência artificial pode ser crítica para o teu negócio. Não pode, por isso, ser um ponto único de falha.
O mito da disponibilidade a 100%
Os fornecedores de LLMs investem enormes recursos em infra-estruturas distribuídas, redundância, replicação e monitorização. Anthropic, OpenAI, Google e outros operadores publicam páginas de estado e compromissos de disponibilidade.
Mas nenhum fornecedor garante que todos os pedidos serão sempre processados, em qualquer região, em qualquer modelo e em qualquer momento.
Um serviço de inteligência artificial depende de uma cadeia complexa:
- autenticação e gestão de sessões;
- gateways de API;
- redes e centros de dados;
- sistemas de filas;
- bases de dados;
- servidores de inferência;
- limites de utilização;
- modelos específicos;
- ferramentas externas ligadas aos agentes;
- serviços de armazenamento e observabilidade.
Basta um destes componentes apresentar problemas para que o efeito seja visível na aplicação final.
E há uma diferença importante entre indisponibilidade e degradação.
Um serviço pode não estar completamente desligado, mas responder de forma lenta, apresentar erros intermitentes, devolver respostas incompletas ou falhar apenas para determinados modelos. Esta situação é particularmente perigosa porque pode não activar um alerta simples de “serviço em baixo”.
O problema também não termina quando o fornecedor recupera.
Imagina um processo que recebe 500 pedidos de clientes. Durante a falha, 100 ficam pendentes. Quando o LLM volta a responder, todos são reenviados ao mesmo tempo. O resultado pode ser uma nova vaga de timeouts, custos duplicados ou respostas repetidas aos mesmos clientes.
A disponibilidade do fornecedor é apenas uma parte da equação. A resiliência da tua arquitectura é a outra.
1. Usa vários modelos e vários fornecedores
A primeira medida de mitigação é evitar a dependência absoluta de um único fornecedor.
Se todo o teu sistema chama exclusivamente o Claude, a falha do Claude torna-se automaticamente uma falha do teu negócio. O mesmo aconteceria se dependesses apenas da OpenAI, da Google ou de qualquer outro operador.
A solução passa por criar uma camada de abstracção entre a tua aplicação e os modelos. A aplicação não deve conhecer todos os detalhes de cada fornecedor. Deve enviar uma tarefa para um serviço interno, que decide qual o modelo mais adequado e disponível.
Por exemplo:
- O sistema tenta executar o pedido no modelo principal.
- Se receber um erro temporário ou exceder o tempo limite, regista o incidente.
- Depois de algumas tentativas controladas, abre o circuito para esse fornecedor.
- Reencaminha o pedido para um segundo modelo, como um modelo da OpenAI ou da Google.
- Se a tarefa for compatível, utiliza também um modelo open-source alojado na tua própria infraestrutura ou num fornecedor alternativo.
Este processo chama-se multi-model fallback.
Não significa que todos os modelos tenham de produzir exactamente a mesma resposta. Significa que deves definir, para cada tipo de tarefa, qual é o nível mínimo aceitável de serviço.
Uma tarefa de resumo pode passar para um modelo mais simples. Uma classificação de documentos pode usar um modelo open-source. Uma decisão de risco pode ser colocada numa fila para revisão humana.
O importante é que a indisponibilidade de um fornecedor não paralise tudo.
2. Implementa degradação graciosa
Quando a IA falha, a aplicação não deve simplesmente apresentar um erro 500 e abandonar o utilizador.
Deves definir antecipadamente o que acontece quando o componente inteligente não está disponível. Esse comportamento é conhecido como graceful degradation, ou degradação graciosa.
Em termos práticos, o sistema reduz temporariamente as suas capacidades, mas mantém o essencial em funcionamento.
Alguns exemplos:
- um chatbot passa para uma mensagem clara e encaminha o pedido para um formulário;
- um sistema de triagem coloca o pedido numa fila para análise humana;
- uma ferramenta de recomendação apresenta opções pré-configuradas;
- um agente deixa de tomar decisões e pede aprovação manual;
- uma automatização utiliza regras estáticas para tarefas simples;
- uma funcionalidade avançada fica indisponível, mas o resto da aplicação continua operacional.
Nem todas as tarefas precisam de inteligência generativa.
Se estás a validar se um campo está preenchido, a confirmar um formato de email ou a aplicar uma regra de preço, não precisas de um LLM. Um conjunto de regras determinísticas é normalmente mais rápido, barato e previsível.
Reserva o modelo para os casos em que acrescenta valor real.
Também deves separar tarefas críticas de tarefas acessórias. O processamento de uma encomenda, a emissão de uma factura ou a validação de uma autorização não devem depender da mesma lógica que gera uma descrição comercial ou sugere um título para um artigo.
Quanto mais crítica for a operação, mais simples e controlável deve ser o seu fallback.
3. Usa retries, timeouts e circuit breakers
Uma falha temporária não deve provocar uma falha permanente. Mas repetir pedidos sem controlo também pode piorar a situação.
Configura tentativas automáticas com:
- timeout definido para cada chamada;
- número máximo de tentativas;
- espera progressiva entre tentativas;
- variação aleatória no intervalo, conhecida como jitter;
- diferenciação entre erros temporários e erros permanentes.
Se um pedido falhar por excesso de tráfego, repetir imediatamente milhares de vezes não resolve o problema. Pelo contrário, aumenta a pressão sobre o fornecedor e sobre a tua própria aplicação.
Usa também um circuit breaker. Quando a taxa de erro ultrapassa um limite, o sistema deixa temporariamente de chamar o fornecedor afectado. Assim, evita perder tempo em pedidos que provavelmente vão falhar e activa o fallback de forma rápida.
Quando o serviço estabilizar, o circuito pode ser testado com alguns pedidos antes de voltar ao funcionamento normal.
Há ainda um detalhe essencial: a idempotência.
Se uma chamada ao LLM desencadeia uma acção — enviar um email, criar uma encomenda ou actualizar um registo — tens de garantir que uma repetição não executa essa acção duas vezes. Guarda identificadores únicos, valida o estado da operação e separa a geração da decisão da execução efectiva.
4. Cria uma cache inteligente
Nem todas as respostas precisam de ser geradas em tempo real.
Perguntas frequentes, classificações repetidas, documentos já processados e conteúdos estáveis podem ser armazenados numa cache. Se o mesmo pedido surgir novamente, o sistema responde a partir dessa informação sem fazer uma nova chamada ao LLM.
Uma cache bem pensada:
- reduz a dependência da API;
- diminui os custos de utilização;
- melhora os tempos de resposta;
- protege contra falhas momentâneas;
- reduz a pressão sobre os fornecedores.
Mas não deves guardar respostas indiscriminadamente.
Define um prazo de validade, identifica o contexto usado para gerar a resposta e invalida a cache quando a informação de origem muda. Uma resposta correcta há três meses pode estar errada hoje.
Para sistemas que consultam informação empresarial, podes combinar cache com uma base de conhecimento local. Assim, o modelo recebe apenas os dados relevantes e, em caso de indisponibilidade, podes continuar a disponibilizar informação previamente validada.
5. Monitoriza a funcionalidade, não apenas o servidor
Verde na página de estado do fornecedor não significa necessariamente que a tua aplicação está a funcionar.
Deves criar health checks que façam testes reais e controlados às integrações de IA. Esses testes podem verificar:
- se a autenticação funciona;
- se o modelo responde dentro do tempo esperado;
- se a resposta tem o formato correcto;
- se o número de tokens está dentro do limite;
- se a ferramenta externa necessária está disponível;
- se a qualidade mínima da resposta é cumprida.
Monitoriza métricas como:
- taxa de erro por fornecedor e por modelo;
- tempo médio e máximo de resposta;
- número de retries;
- pedidos em fila;
- chamadas encaminhadas para fallback;
- custo por operação;
- percentagem de tarefas enviadas para revisão humana.
Define alertas antes de o cliente descobrir o problema.
Também é importante distinguir entre uma falha do fornecedor e uma falha tua. Uma chave expirada, um limite de utilização atingido, um prompt demasiado longo ou uma alteração no formato da resposta podem parecer uma queda do modelo, mas exigem uma correcção diferente.
6. Mantém a arquitectura modular
A IA deve ser uma camada substituível da tua solução, não o alicerce rígido que impede tudo o resto de funcionar.
Numa arquitectura modular, os componentes têm responsabilidades claras:
- a aplicação recebe o pedido;
- o orquestrador decide o fluxo;
- o serviço de IA interpreta ou gera informação;
- as regras de negócio validam o resultado;
- o sistema de execução aplica a acção;
- os registos permitem auditar tudo.
Esta separação torna mais fácil trocar um modelo, adicionar um fornecedor ou desligar temporariamente uma funcionalidade.
Também reduz o risco de ficares preso às particularidades de uma única API. Guarda os prompts, os esquemas de resposta, os testes e as regras de validação num formato que possa ser adaptado a diferentes modelos.
A área de Ferramentas da MQR pode ajudar-te a pensar esta camada tecnológica como parte de uma estratégia digital mais ampla, e não como uma integração isolada feita à pressa.
7. Testa o plano antes da próxima queda
Um plano de contingência que nunca foi testado é apenas uma intenção.
Define cenários concretos:
- o fornecedor principal não responde;
- a API devolve erros durante 30 minutos;
- o modelo fica demasiado lento;
- a autenticação falha;
- a resposta muda de formato;
- o fornecedor atinge o limite de utilização;
- o segundo fornecedor tem uma capacidade inferior.
Depois, testa o comportamento do sistema.
Confirma se os pedidos são colocados em fila, se o fallback é activado, se as acções não são duplicadas e se o utilizador recebe uma mensagem compreensível. Mede também quanto tempo demora a recuperação.
Estabelece dois objectivos:
- RTO — Recovery Time Objective: quanto tempo podes estar degradado até recuperares;
- RPO — Recovery Point Objective: quanta informação podes perder sem comprometer a operação.
Para algumas tarefas, cinco minutos podem ser críticos. Para outras, uma resposta no prazo de algumas horas é suficiente. Não precisas da mesma arquitectura para tudo, mas precisas de tomar essa decisão conscientemente.
A dependência cega é o verdadeiro risco
A queda do Claude em agosto não prova que um fornecedor seja inseguro ou que não devas usar inteligência artificial. Prova algo mais simples: qualquer serviço externo pode falhar.
A questão não é saber se o teu LLM vai cair. É saber o que acontece à tua operação quando isso acontecer.
Um negócio resiliente combina vários modelos, regras determinísticas, cache, monitorização, filas, revisão humana e uma arquitectura modular. Não tenta eliminar todos os riscos. Prepara-se para os absorver sem parar completamente.
Trata os LLMs como infraestrutura crítica. Define alternativas, testa o failover e decide antecipadamente quais as tarefas que podem esperar e quais têm de continuar.
A inteligência artificial pode tornar o teu negócio mais rápido e eficiente. Mas só será verdadeiramente uma vantagem quando o teu negócio continuar a funcionar mesmo quando ela fica temporariamente em silêncio.
