E se uma peça ficar indisponível?

A concentração muda o desenho do risco

O Bank of England destaca que a dependência de poucos provedores de IA pode afetar serviços financeiros quando eles falham, especialmente se a migração para alternativas for difícil. A análise trata do sistema financeiro; não demonstra que toda dependência compartilhada produzirá uma falha sistêmica.

Para a equipe de produto, a pergunta pode ser bem concreta: quais jornadas dependem desta consulta, deste provedor ou deste modelo? Um inventário de fornecedores é insuficiente se não revela os serviços que deixam de funcionar quando uma peça para.

Referência: Bank of England · IA e estabilidade financeira ↗

Uma falha não tem sempre a mesma consequência

Uma busca de informação pode ser adiada. Uma operação de pagamento pode estar pendente de confirmação e não deve ser repetida sem verificar seu estado. Uma falha na assinatura pode impedir a conclusão da formalização, embora outras partes do dossiê continuem disponíveis.

Essas situações pedem respostas diferentes. O contrato precisa tornar visível se houve recusa, indisponibilidade, expiração ou resultado desconhecido. A interface acompanha essa distinção para que o usuário não seja orientado a repetir uma ação que pode já ter ocorrido.

Alternativa não é sinônimo de equivalência

Um adaptador pode concentrar particularidades de um provedor, mas não garante troca imediata. Uma alternativa precisa entregar os campos necessários, preservar significado e atender requisitos operacionais. Autenticação, limites, prazos e efeitos também podem mudar.

Testar uma alternativa significa verificar a jornada completa. Uma resposta tecnicamente válida pode ter semântica diferente. A escolha de fornecedor precisa considerar esse custo de mudança e as condições reais para ativar uma rota secundária.

Meça a recuperação como trabalho de produto

Um exercício útil escolhe uma dependência e observa como a jornada se comporta sem ela. Quem é avisado? O caso pode esperar? Qual ação é bloqueada? Como o trabalho volta ao fluxo depois que o serviço se recupera?

Essa conversa aproxima arquitetura, operação e atendimento. O objetivo não é prometer ausência de falhas, mas evitar estados ambíguos e recuperação improvisada. A continuidade precisa ter responsáveis e critérios de retorno, assim como uma funcionalidade tem critérios de aceite.