Solução · AI Operations
O teu fornecedor de IA vai cair. A pergunta não é se cai, é o que faz a tua operação nessa meia hora.
Monitorizar diz-te que algo falha. A disponibilidade é o que faz o trabalho continuar a sair enquanto falha: segundo caminho, modo degradado, filas que aguentam o golpe e um objetivo de recuperação acordado por caso de uso. Montamos essa função e operamo-la.
O problema
Tratas um fornecedor externo como se fosse uma constante da tua arquitetura.
- Se o teu fornecedor de modelo tem meia hora má, tu tens meia hora má. Não há segundo caminho e ninguém alguma vez testou se poderia haver.
- Todos os agentes falam com o mesmo fornecedor, com a mesma chave e contra a mesma quota. Um pico no agente de marketing consome o limite do agente que fatura.
- Quando o modelo devolve erro, o processo não degrada: para. Não há resposta parcial, nem fila, nem «isto resolvemos em dez minutos»: há um ecrã em branco e um cliente à espera.
- As repetições, onde existem, são imediatas e em ciclo. Quando o fornecedor está saturado, o teu sistema acrescenta-lhe carga e prolonga a sua própria queda.
- Ninguém escreveu quanto tempo pode estar em baixo cada caso de uso. O chat do site e o sistema que emite faturas são tratados da mesma maneira, e não valem nem de perto o mesmo.
- Sabes que houve uma incidência porque um cliente a contou ou porque alguém viu a página de estado do fornecedor por acaso. O aviso chegou por fora.
- O plano para uma queda longa vive na cabeça de uma pessoa. Se a queda acontece a uma sexta-feira à noite e essa pessoa está de férias, o plano não existe.
O custo de continuar igual
Meteste no caminho crítico da tua operação um fornecedor externo cujo estado não controlas, e fizeste-o sem plano B, sem limites e sem acordo interno sobre quanto tempo se pode parar. Isso paga-se de três formas. A primeira é direta: cada incidência do fornecedor é uma incidência tua, com a sua fila de trabalho atrasado e o seu cliente irritado. A segunda é pior porque não se vê: sem isolamento nem controlo de quota, um problema pequeno num sistema secundário leva à frente um crítico, e o diagnóstico custa horas. E a terceira é de credibilidade: quando a direção pergunta quanto tempo isto pode estar em baixo, a resposta honesta hoje é «não sabemos», e é essa resposta que trava o projeto de IA seguinte.
A solução
Montamos a continuidade como função: segundo caminho, degradação controlada e um objetivo acordado por caso de uso
- 1Começamos pelo acordo, não pela arquitetura: que casos de uso estão em produção, quanto tempo pode cada um estar em baixo sem dano real e o que se faz entretanto. Esse objetivo assina-se com o negócio, não o decide a TI sozinha, porque é uma decisão de risco e de custo — a alta disponibilidade paga-se.
- 2Montamos o segundo caminho. Um fornecedor alternativo ou um modelo alternativo para os casos que o justificam, com o encaminhamento preparado e testado, não desenhado num diagrama. O caminho secundário pode dar pior qualidade: isso mede-se de antemão e decide-se se compensa, em vez de se descobrir no dia da queda.
- 3Definimos a degradação controlada, que é a peça que quase ninguém tem. O que faz o sistema quando a IA não está disponível: responder com a parte determinista, meter em fila e avisar do prazo, passar à pessoa de piquete ou devolver uma resposta honesta. Tudo antes do ecrã em branco.
- 4Pomos limites e filas com critério. Quota e chave separadas por sistema para que um pico não coma o orçamento de outro, repetições com espera crescente em vez de ciclos que agravam a queda do fornecedor, e uma fila que absorve o golpe e reprocessa quando o serviço volta, sem perder trabalho pelo caminho.
- 5Isolamos as falhas. Um agente que encrava não deve bloquear o processo inteiro: disjuntores por dependência, tempos máximos por chamada e separação do crítico face ao acessório, para que a queda seja de uma peça e não do sistema.
- 6E operamo-lo. Vigilância do estado dos teus fornecedores integrada com os teus avisos, piquete com manual de incidentes — quem decide mudar de caminho, quando se degrada, como se comunica —, e um simulacro periódico: provoca-se a queda de propósito e cronometra-se a recuperação. Um plano que nunca foi executado não é um plano.
O que muda
O que deixas de perder
Os grandes fornecedores de modelos publicam página de estado pública com histórico de incidentes e manutenções programadas. O dado existe e é consultável; o que falta em quase todas as empresas é que esse dado entre no seu próprio sistema de avisos, em vez de se ir ver à mão quando algo corre mal.
Páginas de estado públicas dos fornecedores (p. ex. status.claude.com), consultadas 2026-08
Os acordos de nível de serviço dos planos empresariais dos fornecedores compensam com créditos, não com continuidade: recuperas parte da fatura, não as horas de operação parada. A continuidade tens de a montar tu, do teu lado.
Mecanismo · condições padrão de SLA com créditos
A queda deixa de ser binária. Com degradação definida, o sistema passa de «não funciona» para «funciona pior e di-lo», que é a diferença entre uma incidência e uma crise.
Mecanismo
O orçamento e a quota deixam de ser um recurso comum sem dono: cada sistema tem a sua chave e o seu limite, por isso um pico no acessório já não consome a capacidade do crítico.
Mecanismo
O que medimos: disponibilidade real por caso de uso (não a do fornecedor), tempo de deteção e tempo de recuperação cronometrados em simulacro, % de pedidos servidos pelo caminho secundário durante um incidente, trabalho em fila reprocessado sem perda, e consumo de quota por sistema face ao seu limite.
O que medimos
Ficha técnica
- Trabalho que elimina
- que uma queda do fornecedor de IA seja uma crise improvisada — sem segundo caminho, sem modo degradado e sem ninguém que saiba quanto tempo se pode estar parado — e que o aviso chegue por um cliente em vez de pelo teu próprio sistema
- Implementação habitual
- 4–8 semanas
- Entrada
- os teus sistemas de IA em produção, as suas dependências de fornecedor e de modelo, as tuas filas e o teu processo de incidentes atual
- Saída
- um objetivo de recuperação acordado por caso de uso, segundo caminho testado, degradação definida em vez de ecrã em branco, filas com repetições e quota por sistema, isolamento de falhas e um piquete com manual e incidentes ensaiados
- Compatível com
- OpenAIAnthropicGoogle Vertex AIAzure OpenAIAmazon BedrockMistralInngestTemporalDatadogPagerDuty
- Pode ligar-se a
- Os teus fornecedores de modelo atuais, sem substituir nenhumO teu gateway ou encaminhador de modelos, se já o tiveresA tua fila de mensagens e a tua camada de repetiçõesA tua observabilidade, os teus alertas e o teu piquete tal como funcionam hoje
- O que medimos
- disponibilidade real por caso de uso, não a do fornecedortempo de deteção e tempo de recuperação cronometrados em simulacro% de pedidos servidos pelo caminho secundário durante um incidentetrabalho em fila reprocessado sem perda depois de uma quedaconsumo de quota por sistema face ao seu limite
- Adequado para
- empresas com IA já no caminho crítico de uma operação real — apoio ao cliente, faturação, logística, back office — onde o CIO, o COO ou o Head of AI têm de responder a quanto tempo isto pode estar em baixo e hoje não conseguem
- Não adequado para
- quem tem um piloto interno sem utilizadores nem consequências — aí a alta disponibilidade é despesa sem retorno e dizemo-lo antes de começar — nem quem procura mudar de fornecedor de modelo por qualidade ou custo: isso é [escolher e mudar de modelo em produção](/soluciones/elegir-y-cambiar-de-modelo-de-ia-en-produccion), outra função diferente
Perguntas frequentes
Em que monitorizar responde a «o que está a acontecer?» e disponibilidade responde a «e entretanto, o quê?». A monitorização instrumenta, mede e avisa: é a camada de deteção e tens-la desenvolvida em monitorizar a IA em produção. Sem ela não dás por nada, por isso é o requisito prévio. Mas um alerta não mantém o trabalho a sair: isso fá-lo o segundo caminho, o modo degradado, a fila que absorve o golpe e o objetivo de recuperação acordado. Podes ter um painel impecável e uma operação parada meia hora, a ver como fica vermelho em tempo real. A regra prática: a monitorização diz-te quando atuar; a disponibilidade decide o que acontece se não atuares a tempo.
Não, e convém ler o que esse SLA compra exatamente. Os acordos de nível de serviço dos fornecedores compensam com créditos sobre a fatura quando não cumprem o objetivo: recuperas dinheiro, não recuperas as horas em que a tua operação esteve parada nem os clientes que se foram embora. Além disso, o objetivo mede-se sobre o serviço do fornecedor, não sobre o teu caso de uso: se o teu processo depende de três chamadas encadeadas mais uma base de dados, a tua disponibilidade real é pior do que a de qualquer das peças em separado, e isso nenhum contrato cobre. O SLA é uma garantia comercial; a continuidade é uma decisão de arquitetura que se toma do teu lado. O que fazemos mesmo com o SLA é usá-lo: os seus objetivos e os seus pré-avisos entram no cálculo do que precisa de segundo caminho e do que não precisa.
Sim, e por isso não se duplica tudo. A redundância aplica-se só onde o objetivo acordado com o negócio a justifica, e esse acordo é o primeiro passo precisamente para não acabares a pagar alta disponibilidade no chat interno dos recursos humanos. Na maioria das empresas com que trabalhamos, um ou dois casos de uso justificam segundo caminho e o resto resolve-se muito mais barato: com degradação bem definida e uma fila que reprocessa quando o serviço volta. O custo que é mesmo fixo é o da disciplina — chaves e quotas separadas, tempos máximos, disjuntores —, e esse paga-se uma vez e evita a classe de incidência mais cara que existe: a que começa pequena num sistema que não interessa e acaba a deitar abaixo o que fatura.
O que tivermos decidido antes para esse caso de uso, e essa é a resposta importante: decide-se com antecedência, não a quente. Os quatro modos que cobrem quase tudo são: passar ao caminho secundário de forma automática quando a degradação de qualidade é aceitável; responder com a parte determinista do processo e deixar em espera apenas o que precisa do modelo; meter o trabalho em fila com um prazo comunicado ao utilizador e reprocessá-lo por inteiro quando o serviço volta; ou escalar para a pessoa de piquete se o caso é crítico e não admite espera. Cada caso de uso tem o seu escrito, com quem o ativa e como se comunica. E ensaia-se: provocamos a queda de propósito com uma periodicidade acordada e cronometramos a recuperação, porque um manual que ninguém executou é um documento, não uma capacidade.
Operamos, porque a disponibilidade não é um entregável: é uma função que se degrada sozinha se ninguém a sustentar. Acrescentas um agente e há que decidir se entra no âmbito; o fornecedor muda os seus limites de taxa e há que reajustar quotas; sai um modelo novo e o caminho secundário de há seis meses já não é a melhor opção; reorganiza-se o piquete e o manual fica com nomes de gente que já não está. A parte de montagem são as quatro a oito semanas iniciais; o que vem a seguir é o piquete, a manutenção dos caminhos, a vigilância do estado dos teus fornecedores e o simulacro periódico. Se preferires que o opere a tua equipa, montamo-lo, documentamo-lo e formamos as pessoas — e dizemo-lo com clareza na proposta, sem te deixar preso a nós por desenho. O resto do catálogo desta função está em AI Operations.
Montamos no teu negócio?
Localizaste o problema. Nós entregamos a solução e deixamo-la medida.