Plataforma
Um sistema de modelos para a entrega séria de software com IA
Routing multi-fornecedor de modelos com fallback: o modelo certo para cada tarefa, trabalho que continua quando um fornecedor degrada, e sem dependência de um único fornecedor.
O sistema de modelos do Ciao é routing multi-fornecedor de modelos com fallback: cada tarefa é encaminhada para um modelo adequado, e quando um fornecedor degrada, o trabalho continua no degrau seguinte. Ao contrário de plataformas ligadas de forma rígida a um fornecedor de IA, o sistema reduz a dependência de qualquer fornecedor único de modelos — e nos planos empresariais pode ser restringido aos seus fornecedores aprovados, às suas próprias chaves ou aos seus modelos privados.
Publicado 2026-07-03 · Última atualização 2026-07-03
Um fornecedor de modelos é um ponto único de falha
O panorama dos modelos muda mensalmente: as capacidades mudam, os preços mudam, os fornecedores têm dias maus. Uma plataforma ligada de forma rígida a um fornecedor herda tudo isso — cada falha torna-se a sua falha, cada decisão de preços torna-se a sua estrutura de custos, cada mudança de roteiro torna-se a sua restrição. As equipas de aquisições começaram a fazer a pergunta diretamente: o que acontece à nossa entrega quando o vosso fornecedor de modelos tem um incidente?
A resposta do Ciao é o sistema de modelos: um sistema de modelos multi-fornecedor com fallback que reduz a dependência de qualquer fornecedor único de modelos. As tarefas são encaminhadas para o modelo adequado a elas, e quando um fornecedor degrada, o sistema recua e o trabalho continua a mover-se.
A mesma lógica aplica-se dentro dos produtos que lança. Se as funcionalidades de IA da sua app dependem de um fornecedor, os seus clientes herdam também os dias maus desse fornecedor. A disciplina de routing ao nível da plataforma protege tanto a construção do software como o próprio software.
Como funciona o sistema de modelos
O sistema é infraestrutura, não uma configuração que gere diariamente — o routing e o fallback acontecem abaixo do nível do pedido.
1. As tarefas são classificadas
Um grande passo de construção, uma edição rápida de interface, a geração de testes e o diagnóstico são tipos diferentes de trabalho — a plataforma trata-os dessa forma.
2. Cada tarefa recebe o modelo certo
O routing associa a tarefa a um modelo adequado em vez de empurrar tudo através de uma única escolha genérica.
3. O fallback ativa-se automaticamente
Quando um fornecedor degrada ou falha, o sistema encaminha para o degrau seguinte. A sua construção não para porque a página de estado de outra pessoa ficou vermelha.
4. Os fornecedores correm sob termos rígidos
A inferência decorre sob contratos de modelo com retenção zero, e o código do cliente não é usado para treinar modelos — em todo o sistema.
5. As empresas definem as fronteiras
Nos planos empresariais, restrinja o routing a fornecedores aprovados, traga as suas próprias chaves de fornecedor, ou aponte para endpoints compatíveis com OpenAI incluindo modelos privados.
Porque é que isto importa
A fiabilidade, a adequação e a posição negocial melhoram todas quando nenhum fornecedor único está por baixo de tudo. A entrega continua através de incidentes de fornecedores, cada tipo de trabalho recebe um modelo adequado a ele, e a sua organização não fica exposta às decisões de preços e roteiro de uma única empresa.
Também protege a longo prazo a escolha da própria plataforma. Os modelos vão continuar a mudar; um sistema absorve essa mudança por trás de um ciclo de entrega estável, para que apostar no Ciao não seja uma aposta em nenhuma geração de modelo em particular. Para as aquisições, isso converte uma pergunta incómoda sobre dependência numa resposta curta com evidência por trás dela — muitas vezes a diferença entre uma plataforma aprovada e uma parada.
Nada disto pede nada às pessoas que constroem. Os pedidos mantêm-se iguais, o Builder mantém-se igual, e o routing faz o seu trabalho de forma invisível até ao dia em que visivelmente salva um prazo.
Quem se importa com o sistema de modelos
O sistema tende a importar mais às pessoas responsáveis pelo que acontece quando as coisas falham:
- Líderes de engenharia e plataforma — Removem um ponto único de falha do pipeline de entrega antes de este falhar no pior momento.
- Equipas de segurança e aquisições — Contratos de retenção zero entre fornecedores, e uma resposta concreta à pergunta sobre dependência de fornecedor em cada RFP.
- Empresas com listas de modelos aprovados — Restringem o sistema a fornecedores sancionados, chaves próprias ou endpoints privados sem abdicar da plataforma.
- Equipas a lançar funcionalidades de IA — A mesma disciplina multi-fornecedor que constrói a app está por trás das capacidades de IA dentro dela.
Notas de segurança e governança
Multi-fornecedor não significa governado de forma solta:
- ✓ A inferência decorre sob contratos de modelo com retenção zero em todo o sistema.
- ✓ O código do cliente não é usado para treinar modelos — qualquer fornecedor, qualquer degrau.
- ✓ Os planos empresariais suportam chaves de fornecedor próprias, endpoints compatíveis com OpenAI e routing de modelos privados.
- ✓ As ações de administração e alterações de configuração chegam ao registo de auditoria apenas de acréscimo.
- ✓ Os relatórios SOC 2 Type II estão disponíveis sob NDA para revisão de segurança.
Fornecedor único vs o sistema de modelos do Ciao
A diferença estrutural aparece em cada modo de falha:
| Configuração de fornecedor único | Sistema de modelos do Ciao | |
|---|---|---|
| Falha de fornecedor | O trabalho para até recuperarem | O fallback encaminha para o fornecedor seguinte |
| Adequação à tarefa | Um modelo para todos os tipos de trabalho | O modelo certo por tarefa |
| Dependência de fornecedor | Total — preços, roteiro, termos | Reduzida entre vários fornecedores |
| Mudanças no panorama de modelos | Um projeto de migração de cada vez | Absorvidas por trás de um ciclo de entrega estável |
| Controlo empresarial | Aceite o fornecedor ou deixe a plataforma | Chaves próprias, modelos privados e routing nos planos empresariais |
Perguntas frequentes
Que fornecedores de modelos usa o Ciao?
O Ciao mantém um sistema multi-fornecedor e ajusta-o à medida que o panorama de modelos muda, que é exatamente o objetivo — sem um único fornecedor por baixo de tudo. Os planos empresariais podem restringir o routing a fornecedores aprovados, às suas próprias chaves, ou a endpoints compatíveis com OpenAI.
Escolho um modelo para cada pedido?
Não. O routing é por tarefa — passos de construção, edições rápidas, testes e diagnóstico vão para modelos adequados automaticamente. As empresas que precisam de controlo definem fronteiras ao nível do plano em vez de microgerir pedidos.
O que acontece durante uma falha de fornecedor?
O fallback ativa-se e o sistema encaminha o trabalho para o fornecedor seguinte, para que as construções continuem. Essa resiliência é uma das principais razões pelas quais equipas sérias perguntam sobre routing multi-fornecedor em primeiro lugar.
O nosso código fica exposto a todos estes fornecedores?
A inferência decorre sob contratos de modelo com retenção zero, e o código do cliente não é usado para treinar modelos — esses termos aplicam-se em todo o sistema. As empresas podem restringir ainda mais quem vê algo usando as suas próprias chaves ou routing de modelos privados.
Podemos correr o sistema sobre os nossos próprios modelos?
Nos planos empresariais, sim — traga as suas próprias chaves de fornecedor ou aponte o routing para endpoints compatíveis com OpenAI, incluindo modelos hospedados de forma privada. Os programas de produção sérios começam em 10.000 USD por ano; fale com as vendas sobre configurações de modelo próprio.
Páginas relacionadas
Construa o software que antes tinha de esperar.
Sistema de Modelos: Routing Multi-Fornecedor, Fallback | Ciao