Enterprise
Traga o seu próprio modelo: chaves, endpoints, contratos
Aponte o Ciao para as relações de modelo em que já confia — as suas próprias chaves de fornecedor, endpoints compatíveis com OpenAI e contratos de retenção zero — em vez de herdar a escolha de fornecedor de outra pessoa.
O LLM próprio no Ciao significa que a sua organização escolhe o fornecedor de modelos por trás dos seus workspaces: traga as suas próprias chaves, ligue endpoints compatíveis com OpenAI, e mantenha a inferência sob contratos de retenção zero. Ao contrário de plataformas presas a um único fornecedor, o Ciao corre um sistema de modelos multi-fornecedor com fallback, para que o seu SDLC de IA não dependa de uma única empresa de modelos — e o código do cliente nunca é usado para treinar modelos.
Publicado 2026-07-03 · Última atualização 2026-07-03
Os seus contratos de modelo fazem parte da sua postura de risco
A esta altura, a maioria das empresas já fez o trabalho difícil uma vez: negociou termos de tratamento de dados com um fornecedor de modelos, reviu cláusulas de retenção e de treino, e aprovou um fornecedor específico junto da segurança e da área jurídica. A última coisa que essa equipa quer é uma plataforma de desenvolvimento que encaminhe silenciosamente o código da empresa através de uma relação de modelo diferente, com termos que ninguém reviu.
Esta é uma lacuna real no mercado de ferramentas de IA. Muitos produtos tratam o modelo como um detalhe de implementação interno — recebe o fornecedor que a plataforma escolheu, nos termos que a plataforma negociou para si própria. Para um programador individual, isso é uma conveniência. Para uma empresa, é um subcontratante não revisto no meio da cadeia de fornecimento de software.
O Ciao trata a escolha de modelo como uma decisão empresarial. Pode trazer as suas próprias chaves de fornecedor, ligar endpoints compatíveis com OpenAI, e alinhar a inferência com os contratos de retenção zero que a sua área jurídica já aprovou — enquanto o próprio sistema de modelos multi-fornecedor da plataforma, com fallback, mantém a entrega resiliente quando um fornecedor individual se degrada.
Há aqui também um argumento de eficiência de compras. Cada relação de modelo que uma plataforma introduz é uma avaliação de fornecedor que a sua equipa tem de conduzir — termos de retenção, cláusulas de treino, postura de incidentes. Encaminhar o desenvolvimento com IA através de acordos de fornecedor que já avaliou significa que a nova plataforma herda trabalho terminado em vez de gerar novas revisões, o que é muitas vezes a diferença entre um trimestre e um ano no calendário de lançamento de uma empresa.
O que o Ciao fornece
- As suas próprias chaves de fornecedor — Encaminhe a utilização de modelos através de chaves que a sua organização controla, para que o consumo, os termos e as relações de fornecedor fiquem sob acordos que negociou — configurados com a equipa enterprise durante o onboarding.
- Endpoints compatíveis com OpenAI — Ligue endpoints que falam a superfície de API compatível com OpenAI, que é como a maioria das gateways de modelos, proxies e configurações de fornecedores aprovados das empresas já está exposta internamente.
- Inferência com retenção zero — A inferência decorre sob contratos de modelo com retenção zero, e o código do cliente não é usado para treinar modelos — as duas cláusulas que a sua revisão vai procurar primeiro.
- Um sistema multi-fornecedor com fallback — O sistema de modelos do Ciao abrange vários fornecedores com fallback, reduzindo a dependência de qualquer fornecedor de modelo único — uma propriedade de disponibilidade e uma posição negocial ao mesmo tempo.
- Auditoria em todo o ciclo — O registo de auditoria apenas de acréscimo regista pedidos, merges, deploys e ações administrativas, para que o trabalho assistido por modelo seja atribuível de ponta a ponta, independentemente de qual fornecedor serviu os tokens.
- Governança independente do modelo — O Guardrails aplica políticas em linguagem simples e regista a revisão humana em alterações arriscadas — a camada de controlo não enfraquece nem muda quando o modelo por trás dela muda.
Como funciona na prática a configuração de um LLM próprio
1. Mapear o seu património atual de modelos
Com a equipa enterprise, liste os fornecedores, gateways e contratos que já tem — a maioria das organizações descobre que já possui os acordos certos para isto.
2. Escolher a postura de routing
Decida que workspaces usam as suas chaves e endpoints, e onde se aplica o próprio sistema multi-fornecedor do Ciao — muitas equipas combinam os dois, usando o seu fornecedor contratado como principal.
3. Ligar e verificar
As chaves e os endpoints compatíveis com OpenAI são configurados para o workspace, e a sua equipa verifica que o tráfego chega onde espera antes de começar o trabalho de produção.
4. Colocar os termos no contrato
Os compromissos de retenção zero e de não-treino são texto contratual revisto durante as compras, não notas de rodapé — a sua área jurídica lê as cláusulas reais.
5. Operar com fallback
Se um fornecedor se degradar, o fallback do sistema de modelos mantém a entrega a andar, e o registo de auditoria continua a registar quem fez o quê ao longo da alteração.
Notas de verificação e comerciais
A configuração do LLM próprio faz parte de um compromisso enterprise, delimitada com a equipa em vez de ativada em self-serve, porque a configuração certa depende das suas gateways, contratos e postura de rede. As afirmações que importam aqui são contratuais: o código do cliente não é usado para treinar modelos, e a inferência decorre sob contratos de modelo com retenção zero — ambas revisíveis no conjunto de documentos durante as compras, ao lado dos relatórios SOC 2 Type II sob NDA. Os programas de produção sérios começam em 10.000 USD por ano. Se a sua estratégia de modelos ainda estiver a formar-se, o sistema multi-fornecedor significa que não é obrigado a decidir hoje: pode começar na postura predefinida do Ciao e mover workspaces para as suas próprias chaves à medida que a sua estratégia de fornecedores assenta.
Duas perguntas que vale a pena fazer em qualquer avaliação desta capacidade: o que acontece quando um fornecedor muda os seus termos, e o que acontece quando um se degrada. O sistema multi-fornecedor existe para que ambas as respostas se mantenham previsíveis — os termos são contratuais por fornecedor, e o fallback mantém a entrega a andar enquanto a conversa com o fornecedor acontece no seu calendário, e não no da falha.
Posturas de modelo no Ciao
| Postura | Quem detém a relação com o fornecedor | Adequação típica |
|---|---|---|
| Sistema de modelos do Ciao | O Ciao, em vários fornecedores com fallback | Predefinição: entrega resiliente sem prisão a um fornecedor |
| As suas próprias chaves | A sua organização, sob os termos que negociou | Empresas com acordos de fornecedor já existentes |
| Endpoint compatível com OpenAI | A sua organização, através da sua gateway ou proxy | Equipas com uma gateway de modelos interna ou lista de fornecedores aprovados |
| Misto | Ambos, por workspace | Principal no seu contrato, fallback para resiliência |
Perguntas frequentes
Que fornecedores podemos trazer?
Qualquer relação de fornecedor que consiga expor através das suas próprias chaves ou de um endpoint compatível com OpenAI, o que cobre as configurações empresariais comuns, incluindo gateways de modelos internas. Os detalhes do seu património são mapeados com a equipa enterprise durante a delimitação do âmbito.
O nosso código é usado para treinar modelos, seja qual for o fornecedor que o serve?
Não. O código do cliente não é usado para treinar modelos, e a inferência decorre sob contratos de modelo com retenção zero. Quando traz as suas próprias chaves, os seus próprios termos negociados também regem essa relação.
O que acontece se o fornecedor escolhido tiver uma indisponibilidade?
O Ciao corre um sistema de modelos multi-fornecedor com fallback, o que reduz a dependência de qualquer fornecedor de modelo único. A forma como o fallback interage com a sua postura de chaves próprias é acordada durante a configuração, para que nada seja encaminhado para onde a sua revisão não aprovou.
Conseguimos ver que atividade de modelo produziu que alteração?
O registo de auditoria apenas de acréscimo regista pedidos, merges, deploys e ações administrativas, para que o trabalho assistido por IA seja atribuível de ponta a ponta. O Guardrails regista adicionalmente a revisão humana em alterações arriscadas, que é normalmente a evidência que os auditores pedem.
A governança depende de qual modelo usamos?
Não. O Guardrails, o QA e a Segurança operam sobre o código e a aplicação em execução, não sobre a confiança num modelo em particular: as políticas aplicam-se em linguagem simples, os testes correm antes e depois da publicação, e os resultados de segurança são confirmados contra a app ao vivo antes de serem sinalizados.