Alternativa ao Claude Cowork: Porque Constroem as Empresas Reguladas a Sua Própria Stack de Coworkers de IA (2026)

Alternativa ao Claude Cowork: Porque Constroem as Empresas Reguladas a Sua Própria Stack de Coworkers de IA (2026)

Se já leu o nosso guia completo do Cowork e o seu instinto lhe diz que ele não pode tocar nos seus workflows mais sensíveis, provavelmente tem razão. O Claude Cowork é uma escolha brilhante para o trabalho para que foi concebido, e uma má escolha para o trabalho regulado, personalizado e sujeito a soberania que enche as agendas das empresas. Aqui está a análise honesta, a arquitetura de referência e as contas do TCO.

Onde o Claude Cowork Realmente se Destaca

O Cowork é a resposta certa quando o seu trabalho envolve dados não sensíveis, a sua equipa tem entre 5 e 500 pessoas e prefere avançar em duas semanas em vez de dois trimestres. A Anthropic acertou em cheio na UX de coworker de IA para esse público, e os quatro pacotes verticais lançados nas últimas seis semanas provam que estão a investir nele como um produto de longo prazo, e não como uma aposta secundária.

Três pontos fortes do Cowork estão bem documentados no nosso cluster de conteúdos:

• Operações de marketing, briefings de conteúdo, pesquisa de audiências, orquestração multicanal. O marketplace de plugins do Cowork e as primitivas de agendamento encaixam perfeitamente na forma como as equipas de marketing realmente trabalham. Veja a nossa análise aprofundada de marketing-ops para os padrões de workflow.
• Equipas jurídicas, triagem de contratos, revisão de redlines, pesquisa jurisdicional. O pacote Legal que a Anthropic lançou a 12 de maio foi o primeiro vertical e continua a ser o mais refinado. Percorremos os casos de uso na nossa análise para equipas jurídicas.
• Pequenas e médias empresas, faturação, acompanhamento de clientes, relatórios leves. O pacote SMB (13 de maio) é genuinamente bom para empresas com menos de ~250 colaboradores que não têm um CISO a respirar-lhes no cangote. A nossa análise do SMB entra em detalhes.

A Anthropic também confirmou que os Serviços Financeiros são o próximo vertical, e a stack de Managed Agents anunciada no Code w/ Claude a 11 de maio eleva o teto do que o marketplace de plugins do Cowork pode fazer. Nada disso está em causa.

O Cowork é a resposta certa para a maioria das empresas na maioria das vezes. Este artigo é sobre o resto — a minoria regulada, sujeita a soberania e com muita PI proprietária, onde o Cowork é a ferramenta errada, mesmo sendo um ótimo produto.

Os 8 Cenários Empresariais em que o Cowork Atinge o Seu Limite

Oito workflows separam o "o Cowork serve" do "o Cowork é impossível": requisitos de residência de dados do GDPR, PHI na saúde, informação classificada de defesa/governo, confidencialidade de data rooms de M&A, finanças reguladas sob a SEC/FINRA, proteção de PI proprietária, amplitude de servidores MCP personalizados além dos cerca de 20 que a Anthropic disponibiliza, e padrões de orquestração de agentes para os quais a Anthropic não os concebeu. Cada um destes é um critério de sim/não, não uma preferência.

Se leu essa tabela e duas ou mais linhas descrevem o seu negócio, já ultrapassou a linha do "o Cowork serve". Continue a ler.

A Arquitetura de Referência do Coworker em Infraestrutura Própria

Uma stack de coworker de IA em infraestrutura própria para produção tem sete camadas: inferência, gateway, memória, orquestração de agentes, ferramentas (servidores MCP), RBAC/auditoria e UI. Cada camada tem duas ou três opções reais em 2026, e a stack é suficientemente componível para poder trocar qualquer uma delas sem reescrever as outras. Aqui está o que cada camada faz, o que usamos com mais frequência e com o que deve ter cuidado.

Camada 1 — Inferência (o modelo)

É aqui que o LLM realmente corre. Tem quatro caminhos práticos:

1. API direta da Anthropic, a mais rápida, o menor overhead de engenharia, mas volta a estar no caminho de dados da Anthropic. Aceitável se a sua preocupação é a orquestração personalizada, mas não a residência de dados.
2. OpenRouter, uma única API para mais de 100 modelos. Ótimo para desenvolvimento e testes de comparação de modelos, menos bom para auditoria empresarial.
3. Bedrock ou Vertex AI, endpoints privados cloud-native com fixação por região. O Anthropic Claude está disponível em ambos. Este é o compromisso empresarial mais comum: obtém qualidade de classe Claude com compliance cloud-native.
4. Inferência on-prem, vLLM em hardware H100/H200 a correr modelos de pesos abertos. Llama 3.3 70B, DeepSeek V3, Qwen 3 ou Mistral Large. O único caminho para IL5/IL6 e o mais caro em capex.

A Anthropic não disponibiliza os pesos dos modelos Claude, pelo que o on-prem verdadeiro com o Claude é impossível. Se tem de estar on-prem, está a escolher entre modelos de pesos abertos, e a diferença de qualidade para o Claude Opus 4.7 reduziu-se significativamente nos últimos 18 meses, mas não está fechada.

Camada 2 — Gateway de LLM

O gateway fica entre cada aplicação e cada modelo. O seu trabalho é o failover, o encaminhamento por custo, o registo de auditoria, a limitação de taxa e (criticamente) a abstração da escolha do modelo, para que possa trocar de caminhos de inferência sem tocar no código da aplicação.

Opções para produção:

• LiteLLM, open-source, auto-alojável, API compatível com OpenAI para mais de 100 fornecedores. Gratuito.
• Portkey, gateway gerido com dashboards de observabilidade integrados. Bom para equipas que não querem operar o LiteLLM elas próprias.
• Helicone, observabilidade em primeiro lugar; combina bem com o LiteLLM em vez de o substituir.

Esta camada é inegociável em produção. Saltá-la significa codificar em duro a escolha do modelo na sua aplicação e, depois, reimplementar sempre que a Anthropic lança um novo modelo ou a sua equipa de segurança exige um failover regional.

Camada 3 — Memória e Recuperação

Três subsistemas vivem aqui:

• Vector store, Pinecone (gerido, o caminho mais rápido) ou Qdrant (auto-alojável, a escolha certa para requisitos on-prem). Weaviate e pgvector também são válidos; o Qdrant tem a proposta empresarial mais limpa neste momento.
• Memória estruturada, Postgres para tudo o que beneficia de SQL. A maior parte da "memória de agente" é, na verdade, relacional, não semântica.
• Contexto de curto prazo, Redis ou DynamoDB para estado de sessão, cache de conversas recentes e resultados intermédios de agentes.

Acerte nesta camada e os seus agentes parecem lembrar-se das coisas. Errar aqui e cada conversa começa do zero, o que é aceitável para um chatbot e fatal para um coworker.

Camada 4 — Orquestração de Agentes

É aqui que as primitivas de agendamento do Cowork deixam de ser suficientes. Opções:

• LangGraph, supervisão multiagente baseada em grafos. Melhor para workflows com encaminhamento condicional, retries e aprovação com intervenção humana.
• CrewAI, equipas de agentes baseadas em funções. Uma abstração mais limpa para padrões "analista de pesquisa + escritor + revisor".
• DAG personalizado, para equipas com forte experiência em sistemas distribuídos; dá-lhe controlo total à custa de construir tudo sozinho.

Para a maioria das empresas, implementamos o LangGraph porque o modelo de grafo facilita a história de auditoria — cada transição é registada, cada decisão é inspecionável. (E o crédito de $500 do Anthropic Agent SDK que cobrimos aqui subsidia frequentemente os primeiros três meses de desenvolvimento da Camada 4.)

Camada 5 — Ferramentas (servidores MCP)

Cada integração interna torna-se um servidor MCP. Salesforce, Snowflake, Jira, Confluence, Workday, o seu data lake, a sua API interna de RH. A especificação do Model Context Protocol está agora estável e disponível em todos os principais frameworks de agentes. Escreve um servidor por fonte de dados; a camada de agentes descobre-os em tempo de execução.

Esta é a camada onde o marketplace de plugins do Cowork falha para as empresas. A Anthropic faz a curadoria do marketplace, lentamente e ao seu próprio ritmo. Uma camada MCP em infraestrutura própria permite-lhe lançar um servidor para um módulo SAP legado numa semana, não num trimestre. Tipicamente construímos 15–40 servidores MCP por projeto empresarial.

Camada 6 — RBAC + Registo de Auditoria

É aqui que os reguladores decidem se a sua stack avança. Os componentes:

• Motor de políticas, Open Policy Agent (OPA) ou AWS Cedar. Cada chamada de ferramenta e cada chamada de modelo passa pela avaliação de políticas. Por utilizador, por função, por classe de dados.
• Pipeline de auditoria, cada prompt, cada resposta, cada chamada de ferramenta, cada modelo selecionado, cada custo incorrido, registado com retenção total. Usamos traces do OpenTelemetry a fluir para um SIEM em cloud regulada ou um arquivo S3 de longo prazo com compliance WORM.
• Deteção de PII/PHI, Presidio ou um pipeline DLP personalizado no gateway. Ocultar antes de registar; nunca deixar PHI em bruto chegar ao seu armazenamento de auditoria.

Esta camada é invisível para os utilizadores finais e é a razão pela qual as empresas realmente pagam pela construção. É também a camada que o Cowork não lhe pode dar, estruturalmente, porque o limite de auditoria não inclui a infraestrutura deles.

Camada 7 — UI

A vantagem da app de desktop que o Cowork tem na Camada 7 desaparece quase totalmente para as empresas, porque a maioria dos utilizadores empresariais já vive dentro do Slack, do Microsoft Teams ou de um portal web personalizado. Opções práticas de UI:

• Bot de Slack ou Teams, o caminho mais rápido para a adoção dentro dos workflows existentes.
• App web personalizada, Next.js ou o seu portal interno existente, com uma superfície de agente integrada.
• App de desktop personalizada, o Electron continua a ser a resposta prática se quer a experiência de "terceiro separador" ao estilo Cowork. A maioria das empresas não precisa dela.

Escolha a superfície em que os seus utilizadores já vivem. O argumento de lock-in de modelo aqui é o inverso do Cowork: em vez de forçar os utilizadores a entrar numa nova app, a sua stack vai ao encontro deles onde estão.

Isto é uma stack de 7 camadas, não um projeto de fim de semana. As próximas duas secções quantificam quanto custa e quanto tempo demora.

TCO a 5 Anos, Lugares de Cowork vs. Stack em Infraestrutura Própria

A 200 lugares, o Cowork Enterprise ganha em custo. A mais de 1.000 lugares ao longo de cinco anos, a construção em infraestrutura própria cai para cerca de $2/lugar/dia no total, e cruza o TCO do Cowork algures entre os 600 e os 800 lugares. Esse cruzamento só importa, porém, se nenhuma outra barreira (residência de dados, orquestração personalizada, PI) já tiver forçado a construção. Para a maioria das empresas reguladas, a comparação de TCO é uma verificação de sanidade, não um fator de decisão.

"5-Year TCO: Cowork Enterprise vs. Self-Hosted (200 seats)"

Tabela de dados

"5-Year TCO: Cowork Enterprise vs. Self-Hosted (200 seats)"

"Sourcing Option"	"5-Year Total"
"Cowork (200 seats × $60/mo)"	720
"Self-Hosted (200 seats, build + 4yr ops)"	1850
"Self-Hosted (1,000 seats, amortised)"	2150

Os pressupostos por detrás desses números, porque artigos de TCO que escondem pressupostos são inúteis:

• Cowork Enterprise, preço de tabela de $60/lugar/mês para o tier Enterprise com residência na UE e add-on de BAA, ×200 lugares × 60 meses = $720K. Sem add-ons de marketplace incluídos.
• Infraestrutura própria, 200 lugares, custo de construção do Ano 1 de $850K (equipa de seis engenheiros durante dois trimestres, capex de infra, vector store, stack de observabilidade), mais operações dos Anos 2–5 a $250K/ano (equipa de operações de dois engenheiros, uso de modelos, opex de infra). Total: $1.85M.
• Infraestrutura própria, 1.000 lugares, mesma construção do Ano 1 ($850K), operações dos Anos 2–5 escalam para $325K/ano (o uso de modelos cresce com os utilizadores; a engenharia mantém-se praticamente estável). Total: $2.15M, ou cerca de $2.15/lugar/dia em média ao longo de cinco anos.

A linha interessante é a terceira. O custo de engenharia numa stack em infraestrutura própria é maioritariamente fixo — dois engenheiros conseguem manter uma stack que serve 100 lugares ou 10.000. O uso de modelos escala com os utilizadores, mas comprime à medida que faz batch e cache. O cruzamento de TCO com o Cowork é real, mas acontece a uma escala que a maioria das empresas só atinge se expandir a plataforma por muitas divisões.

Se está nos 50 lugares e os seus dados não são regulados, o Cowork ganha em todos os eixos. Se está nos 5.000 lugares e tem um CISO, a construção em infraestrutura própria paga-se a si própria antes do Ano 3. A matemática inverte-se por volta dos 600–800 lugares, e a maioria dos pilotos empresariais está nesse intervalo ou acima.

Time-to-Value, A Curva Que Surpreende os CFOs

O Cowork é utilizável na primeira semana e atinge um patamar no segundo mês. A solução em infraestrutura própria cresce lentamente durante o Q1, ultrapassa o Cowork por volta do sexto mês e continua a subir. A pergunta do CFO não é "qual é mais rápido", é "qual curva corresponde ao nosso perfil de risco e ao nosso horizonte de planeamento."

"Time-to-Value: Cowork vs. Self-Hosted (12 months)"

Tabela de dados

"Time-to-Value: Cowork vs. Self-Hosted (12 months)"

"Months"	"Cowork"	"Self-Hosted"
"M1"	70	5
"M2"	80	15
"M3"	80	35
"M4"	80	55
"M5"	80	70
"M6"	80	80
"M9"	80	92
"M12"	80	100

Três coisas que este gráfico subestima:

1. A pontuação do Cowork no Mês 1 é alta porque é um produto, não um projeto. A Anthropic entregou a UX e as integrações; adota-as. A diferença de 30 pontos no Mês 1 é real, e importa quando está a tentar demonstrar o ROI da IA a um conselho de administração que ouve falar disso há dois anos.

2. A curva da infraestrutura própria não é linear porque o trabalho não é linear. Os Meses 1–2 são arquitetura, seleção de fornecedores e a infraestrutura base das Camadas 1–2. Os Meses 3–4 são os primeiros lançamentos reais de agentes na stack. Os Meses 5–6 são quando o custo marginal do agente número 5 cai para uma fração do custo do agente número um. Esse é o ponto de inflexão, e a razão pela qual construir uma plataforma parece frustrantemente lento nos primeiros 90 dias.

3. O patamar do Cowork é real, não uma calúnia. O Cowork é excelente naquilo para que a Anthropic o entrega. Não foi concebido para se estender para além desse âmbito, e o marketplace existe precisamente para que não tenham de continuar a estendê-lo eles próprios.

Percorremos a mesma forma de curva na nossa análise de construir vs. comprar para agentes de voz IA — os princípios transferem-se. Se o seu caso de negócio vive ou morre nos resultados do Mês 3, compre. Se vive nos resultados do Mês 12, construa.

A Matriz de Decisão de Construção Própria

Pontue estas sete perguntas com 0, 5 ou 10. Se pontuar acima de 25, construa a sua própria. Entre 15 e 25, pilote o Cowork e reavalie. Abaixo de 15, fique no Cowork. A matriz é a peça de maior sinal deste artigo; se guardar algo nos favoritos, guarde a tabela.

Aplicámos esta matriz em mais de 30 projetos de integração de IA nos últimos 18 meses. A proporção de organizações a pontuar acima de 25 passou de cerca de 30% no final de 2024 para cerca de 55% em maio de 2026 — impulsionada sobretudo pela aplicação do GDPR e pela Regra de Divulgação de IA de 2025 da SEC. A mudança não é ideológica; é regulatória.

Um padrão a notar: as pontuações tendem a concentrar-se nos extremos. As empresas pontuam 5–15 (o Cowork é obviamente a escolha certa) ou 35–70 (a infraestrutura própria é obviamente a escolha certa). A faixa intermédia de 15–25 é mais rara do que parece, e representa geralmente empresas à beira de cruzar uma linha regulatória sem ainda se aperceberem de que se estão a aproximar dela.

Quando o Cowork Ainda Ganha, Mesmo à Escala Empresarial

Mesmo dentro de empresas que pontuam 50+ na matriz, o Cowork ainda ganha para três padrões: a equipa de marketing não regulada, o prototipar-antes-de-comprar de 90 dias, e o complemento para plataformas de IA internas maduras. Alojar tudo em infraestrutura própria é tão errado como comprar tudo; a competência está em encaminhar cada workflow para a stack certa.

Os três padrões:

• A equipa de marketing não regulada dentro de uma empresa regulada. Uma empresa farmacêutica não pode colocar PHI no Cowork, mas a sua equipa de marketing de marca não está a tocar em PHI — está a escrever briefings de campanhas e a analisar o desempenho dos canais. O Cowork funciona aí. Encaminhar trabalho de baixa sensibilidade para o Cowork e trabalho de alta sensibilidade para a stack interna é a arquitetura óbvia, mas raramente implementada, e cobrimos a questão da substituição do gestor de marketing em detalhe noutro artigo.

• Padrões de prototipar-antes-de-comprar. Use o Cowork durante 60–90 dias para provar que o workflow funciona com dados reais e utilizadores reais. Se o ROI aparecer, então construa. Se não aparecer, gastou $20K em lugares de Cowork em vez de $200K numa construção que resolve um problema que não tinha. O piloto de 90 dias do Cowork é o exercício de recolha de requisitos de mais alta qualidade na IA empresarial.

• Empresas maduras que já têm plataformas de IA internas. Se já construiu a stack de 7 camadas para trabalho de alta sensibilidade, acoplar o Cowork à superfície de baixa sensibilidade é rápido, barato e reduz o risco de "shadow IT" de equipas a adotar ferramentas de IA por conta própria.

O ponto forte do Cowork nas pequenas empresas aplica-se também dentro das empresas — para qualquer subequipa que opera como uma pequena empresa, o Cowork é estruturalmente a ferramenta certa, independentemente do perfil regulatório da empresa-mãe.

A infraestrutura própria é a resposta certa para cargas de trabalho sensíveis. O Cowork é a resposta certa para tudo o resto. A competência está em saber qual é qual, e não fingir que é binário.

Como a Techsy Constrói Integrações de IA Empresariais

Entregámos mais de 30 projetos de integração de IA desde 2024, em finanças reguladas, setores adjacentes à saúde, adjacentes à defesa e marcas de consumo sensíveis à PI. A metodologia não mudou muito porque a arquitetura não mudou muito — são as mesmas sete camadas, personalizadas por perfil regulatório.

A metodologia de quatro fases:

1. Fase 1 — Workshop de arquitetura e TCO (2 semanas, preço fixo). Pontuamos a matriz de decisão com a sua equipa, desenhamos a arquitetura de 7 camadas para as suas restrições e construímos o modelo de TCO honesto. Sai com um artefacto funcional, independentemente de nos contratar para a Fase 2.

2. Fase 2 — Construção de referência (8–12 semanas). Um agente de produção na stack completa de 7 camadas, tipicamente o workflow de maior valor e menor risco político que identificámos na Fase 1. Pronto para produção, não uma demo. Usamos o Anthropic Agent SDK e o crédito de $500 que cobrimos aqui para subsidiar o trabalho inicial da Camada 4, quando aplicável.

3. Fase 3 — Expansão da plataforma (3–6 meses). Agentes 2 a N na mesma stack. É aqui que o custo marginal de cada novo agente colapsa, geralmente para 30–60% do custo da construção de referência da Fase 2. A stack de 7 camadas torna-se uma plataforma.

4. Fase 4 — Transição e operação (contínuo). A sua equipa é dona da stack. Ficamos em avença para atualizações de modelos, novos servidores MCP e revisões trimestrais de arquitetura.

A stack que entregamos por defeito em 2026: Anthropic Claude Opus 4.7 + LangGraph + Pinecone (ou Qdrant para on-prem total) + gateway LiteLLM + vLLM para caminhos de inferência on-prem, por detrás de RBAC com políticas OPA e observabilidade OpenTelemetry. Cada componente é substituível; nada é feito à medida só por ser feito à medida. A plataforma de implementação de IA agêntica que usamos embrulha esta stack numa superfície implementável, e a nossa prática de desenvolvimento de agentes cobre o modelo de engenharia em profundidade.

Se quiser pontuar a matriz connosco e ver como seria a sua arquitetura de 7 camadas, marque uma chamada de arquitetura gratuita de 30 minutos com a nossa equipa. Sem pré-requisitos, sem slides — percorremos as suas restrições e esboçamos a stack em direto.

Observar o Produto Que Criticamos Respeitosamente

A Anthropic entregou um produto genuinamente bom. Os próximos treze minutos valem o seu tempo — é a articulação mais clara daquilo para que serve o Cowork, pela equipa que o construiu.

Veja-o antes de se comprometer com qualquer um dos caminhos. Se, depois de ver, achar que o Cowork resolve o seu problema, compre o Cowork. Se se encontrar a pensar "isto é ótimo, mas...", a segunda metade deste artigo é para si. Não somos anti-Cowork. Somos contra comprar a ferramenta errada para o seu perfil regulatório.

Caminho de Migração, Do Piloto de Cowork à Produção em Infraestrutura Própria

O padrão mais comum que vemos em 2026 não é Cowork-ou-infraestrutura-própria. É Cowork-depois-infraestrutura-própria, com um plano de migração limpo. Aqui está o caminho de quatro etapas que recomendamos:

1. Meses 0–3 — Piloto de Cowork. Prove o workflow em utilizadores reais com dados reais (apenas workflows de baixa sensibilidade). Documente o que funciona, o que falha, o que gostaria que fosse diferente.
2. Meses 3–4 — Decisão de arquitetura. Pontue a matriz com os dados da Fase 1. Se pontuar acima de 25, comprometa-se com a construção. Ainda não desligue o Cowork.
3. Meses 4–10 — Construção em paralelo. Construa a stack de 7 camadas em paralelo com o uso continuado do Cowork. Os workflows não sensíveis ficam no Cowork; a construção visa os workflows regulados.
4. Meses 10–12 — Transição por workflow, não por departamento. Os workflows sensíveis migram primeiro para infraestrutura própria; os workflows não sensíveis podem ficar no Cowork indefinidamente se o encaminhamento fizer sentido.

A regra de transição é aquela que a maioria das equipas erra. Migrar por departamento cria um problema político de marcha forçada; migrar por tipo de workflow permite a cada equipa adotar a ferramenta certa para o trabalho que tem à frente. A matriz de decisão pontua por workflow, não por departamento, pela mesma razão.

Também vimos o padrão inverso, infraestrutura-própria-depois-Cowork, em empresas que construíram cedo e agora querem dar às suas equipas não reguladas uma superfície rápida. A comparação com o ChatGPT Agents é a referência certa se está preso a escolher entre o Cowork e um produto de compra concorrente depois de se comprometer com uma arquitetura híbrida.

FAQ

Construir a sua própria não é muito mais caro?

Nem sempre, e raramente de forma simples. A 200 lugares, o Cowork ganha em custo ao longo de cinco anos. Entre 600 e 800 lugares as curvas cruzam-se, e a mais de 1.000 lugares a infraestrutura própria é mais barata. Mais importante: se pontuar 25+ na matriz de decisão, a comparação de custos é teórica — os requisitos regulatórios ou de soberania já tomaram a decisão por si.

Quanto tempo demora a lançar uma stack de agentes empresarial em infraestrutura própria?

8–12 semanas para o primeiro agente de produção na stack completa de 7 camadas, 3–6 meses para a plataforma (agentes 2 a N) e contínuo para o ciclo de atualizações de modelos. O Cowork lança em 1–2 semanas. A maioria das empresas troca a diferença de 8 semanas por soberania e personalização; as que não o fazem não são empresas que precisassem de construir.

Podemos começar com o Cowork e migrar mais tarde?

Sim, este é o padrão mais comum que vemos em 2026. Use o Cowork nos Meses 0–3 para provar o workflow, construa a stack de 7 camadas em paralelo nos Meses 4–10 e depois faça a transição por tipo de workflow em vez de por departamento. A migração é mais difícil do que começar em infraestrutura própria desde o primeiro dia, mas muito mais rápida do que construir às cegas.

E o Trust Center do Claude Enterprise?

O Trust Center da Anthropic cobre SOC 2 Type II, ISO 27001, residência de dados na UE no Enterprise e BAA para a saúde. É uma proposta forte para o que cobre. Não cobre ITAR, requisitos de cloud soberana IL5/IL6, isolamento hermético de data rooms de M&A, nem workflows em que o próprio conteúdo do prompt é classificado ou regulado. O Trust Center é necessário para alguns cenários e estruturalmente insuficiente para outros.

É permitida a implementação on-prem de modelos da Anthropic?

Não. A Anthropic não disponibiliza os pesos dos modelos Claude, pelo que a inferência on-prem verdadeira do Claude é impossível em 2026. O alojamento on-prem em infraestrutura própria requer alternativas de pesos abertos — Llama 3.3, DeepSeek V3, Qwen 3 ou Mistral Large a correr em vLLM. O Bedrock e o Vertex oferecem opções de endpoints privados que alguns reguladores aceitam como o equivalente prático de on-prem; confirme com a sua equipa de compliance antes de assumir.

Qual é o custo de manutenção contínuo ao longo do tempo?

Cerca de $250K/ano para uma equipa de operações de 2 engenheiros, mais uso de modelos e infraestrutura à escala de 200 lugares. Esse valor sobe para cerca de $325K/ano a 1.000 lugares — a maior parte do custo é engenharia fixa, não infraestrutura variável. O uso de modelos escala com os utilizadores, mas comprime à medida que faz batch, cache e encaminha consultas mais pequenas para modelos mais baratos através da camada de gateway.

Quem é dono dos prompts e das ferramentas que desenvolvemos?

Você é, totalmente, numa stack em infraestrutura própria. No Cowork, os prompts são armazenados na infraestrutura da Anthropic sob os seus termos comerciais — aceitável para a maioria das empresas, um fator de exclusão para setores de PI proprietária (marcas de consumo, biotecnologia, finanças reguladas). A questão da propriedade é uma das razões subestimadas pelas quais as empresas maduras alojam em infraestrutura própria.

Suportam híbrido, alguns workflows no Cowork, outros em infraestrutura própria?

Sim, e recomendamos-no mais frequentemente do que a infraestrutura própria pura. Encaminhe workflows de baixa sensibilidade para o Cowork e os de alta sensibilidade para a sua stack interna. Um gateway LiteLLM pode distribuir por tipo de workflow com regras de encaminhamento simples, e as suas camadas de auditoria e políticas podem tratar as duas superfícies de forma uniforme.

Como lidam com o ciclo contínuo de atualizações de modelos numa stack em infraestrutura própria?

O gateway LiteLLM abstrai a escolha do modelo. Quando a Anthropic lança um novo modelo, aponta uma configuração para ele. Quando um modelo de pesos abertos ultrapassa o incumbente de código fechado numa tarefa específica, redireciona essa carga intensiva em computação para o vLLM sem tocar no código da aplicação. A arquitetura de 7 camadas é explicitamente concebida para o proteger do lock-in de modelo, o que o Cowork, por conceção, não pode fazer.

Conclusão

O Cowork é um ótimo produto para o trabalho para que foi construído, e não é a resposta certa para empresas reguladas com restrições de soberania, PI ou orquestração personalizada. A arquitetura de referência em infraestrutura própria de 7 camadas neste artigo é a mesma que entregámos mais de 30 vezes desde 2024; a matriz de decisão é o artefacto que percorremos com cada cliente na Fase 1. Leia o guia completo do Cowork se ainda não o fez, e depois volte aqui quando estiver pronto para falar de arquitetura.

Se quiser uma versão funcional da matriz de decisão e um rascunho da arquitetura de 7 camadas para as suas restrições, contacte-nos — esboçamo-lo em direto e sai com o artefacto, quer trabalhemos juntos depois ou não.