Para quem é este guia
CIO, CTO, CISO, head de inovação e líderes de workplace/TI que precisam escolher camada de assistência de IA para conhecimento e produtividade — documentos, e-mail, reuniões, busca interna — e, em alguns casos, bases para agentes leves.
Este guia de compra de IA de produtividade não é um comparativo de bench com notas. É um mapa de decisão: qual família de solução entra no shortlist conforme identidade, dados, risco e capacidade de engenharia. Pontue com a metodologia de comparativos v1 (scorecard interno A–G), sem inventar scores de vendor.
Preços de lista, SKUs e bundles mudam. Qualquer valor publicado deve ser cotado com o fornecedor/parceiro na data da compra e citado com data — aqui deliberadamente não inventamos números.
Quatro famílias (não quatro “produtos únicos”)
1. Microsoft 365 Copilot (ecossistema Microsoft)
Assistência embutida no grafo de trabalho Microsoft (Word, Excel, PowerPoint, Outlook, Teams, entre outros pontos do ecossistema, conforme SKU e rollout). Tipicamente se apoia em identidade Entra ID, controles de compliance da suíte e permissões já existentes nos arquivos e caixas de correio.
Sinais de fit: organização já padronizada em Microsoft 365; SharePoint/OneDrive/Teams como sistema de fato do conhecimento; time de workplace maduro; desejo de IA “no fluxo” sem novo front-end.
Sinais de não-fit (relativos): stack de colaboração majoritariamente não-Microsoft; necessidade de modelo/provider distinto com controle fino; cenários que exigem self-host de pesos; customização profunda de agentes além do que a suíte oferece nativamente — validar roadmap e produtos adjacentes (Studio/agents) na documentação vigente.
2. Google (Workspace + Gemini / Vertex, conforme arquitetura)
Família que cobre assistência no Workspace e, em arquiteturas mais avançadas, capacidades via Google Cloud (ex.: Vertex) para casos que saem da produtividade pura. A fronteira exata entre “copilot de workspace” e “plataforma de IA” depende do desenho — não misture SKUs na cabeça do comitê.
Sinais de fit: Google Workspace como colaboração padrão; dados relevantes no Drive/Gmail/Docs; time já em GCP ou aberto a isso para casos avançados.
Sinais de não-fit (relativos): lock-in Microsoft difícil de conviver; requisitos contratuais que empurram outro provedor; necessidade de isolamento que o desenho Workspace+cloud não atenda sem projeto — verificar com arquitetura e jurídico.
3. Claude Enterprise (e congêneres de “LLM enterprise” desacoplados da suíte)
Aqui o valor central é o modelo e o ambiente enterprise de uso (governança de workspace, SSO, controles de retenção/treino conforme plano contratual), não o embed nativo em cada célula do Excel. Na prática, entra como camada de raciocínio/chat/API para knowledge work e desenvolvimento de soluções, podendo coexistir com Microsoft ou Google.
Sinais de fit: times de conhecimento e engenharia querem modelo forte em raciocínio/código/análise longa; política de dados alinhada ao contrato enterprise; uso via workspace e/ou API com controles.
Sinais de não-fit (relativos): expectativa de “Copilot idêntico ao Outlook/Sheets” sem projeto de integração; ausência de dono para governar workspaces e chaves.
Outros provedores de LLM enterprise existem na mesma família conceitual (chat/API enterprise desacoplada). Este guia usa Claude Enterprise como âncora ilustrativa dessa categoria; um RFP sério deve incluir alternativas relevantes à época — sem fingir bake-off.
4. Open-source / self-host (modelos + RAG + gateway)
Stack em que a organização (ou parceiro) opera modelos open-weights ou gateways, frequentemente com RAG sobre bases internas, políticas próprias e observabilidade própria. Pode rodar on-prem, VPC ou cloud com isolamento.
Sinais de fit: requisito forte de controle/residência; time de plataforma capaz; casos estáveis o suficiente para justificar operação; sensibilidade a enviar certos dados a provedores externos.
Sinais de não-fit (relativos): time de TI enxuto sem SRE/MLOps; expectativa de UX “igual Copilot” em todos os apps Office/Workspace sem esforço massivo; subestimar custo de qualidade (avaliação, red team, patches).
Critérios de decisão (use como scorecard interno)
Atribua pesos alinhados à metodologia v1 (ou 1–5 locais documentados). Pontue shortlist com evidência (demo + docs + DPA), não com feeling de keynote — e sem scores públicos inventados neste guia.
A. Identidade e permissões
- A IA respeita ACLs existentes (arquivo que o usuário não lê, o copiloto não resume)?
- SSO/OIDC/SAML com nosso IdP?
- Há trilha de quem ativou features por área?
B. Superfície de trabalho
- A IA aparece onde o trabalho já acontece (e-mail, docs, planilha, reunião)?
- Ou exige novo destino (chat corporativo) que o usuário pode ignorar?
C. Dados, LGPD e postura contratual
- Tratamento de prompts e uploads no DPA vigente;
- Uso para treino de modelos de terceiros: o que o contrato diz hoje;
- Residência / subprocessadores;
- Retenção e eDiscovery / legal hold, se aplicável à sua indústria.
D. Segurança e compliance de workplace
- Integração com DLP / etiquetas de sensibilidade já adotadas;
- Controles por grupo (piloto vs. toda empresa);
- Logs administrativos exportáveis.
E. Extensibilidade e agentes
- Conectores a sistemas internos;
- Capacidade de agents com tools e aprovação humana;
- Como isso se conecta ao inventário e à governança de agentes (âncoras 01–03).
F. Qualidade e mudança de modelo
- Você aceita que o provedor altere o modelo detrás do SKU?
- Precisa pin de versão / controle de roteamento?
- Há processo interno de avaliação de regressão?
G. TCO e operação
Componha:
- Licenças por usuário / add-ons;
- Consumo API (se houver);
- Preparação de dados (hígiene de SharePoint/Drive — custo escondido clássico);
- Enablement (treinamento, champions);
- Segurança/privacidade contínuos;
- Engenharia (mais alta em self-host e em integrações profundas).
Não compare só preço de seat. Um Copilot “mais caro” na planilha pode sair mais barato que self-host mal dimensionado — ou o inverso, se o caso for API pesada e time forte. Use cotação real.
H. Risco de concentração
- Já somos dependentes demais do mesmo cloud vendor?
- Precisamos de multi-modelo por política?
Mini-tabela BR — residência, treino e subprocessador
Valores mudam por SKU, região e adendo contratual. Trate cada célula como “verificar no SKU cotado” — não como fato permanente.
| Família | Residência / processamento | Treino com dados do cliente | Subprocessadores |
|---|---|---|---|
| Microsoft 365 Copilot | Verificar no SKU cotado (tenant, região, docs de compliance do pacote) | Verificar no SKU cotado / DPA vigente | Verificar lista do pacote cotado |
| Google (Workspace / Gemini / Vertex) | Verificar no SKU cotado (Workspace vs. Cloud podem divergir) | Verificar no SKU cotado / DPA vigente | Verificar lista do pacote cotado |
| Claude Enterprise (âncora da família LLM enterprise) | Verificar no SKU cotado | Verificar no SKU cotado / DPA vigente | Verificar lista do pacote cotado |
| Open-source / self-host | Sob seu desenho (on-prem, VPC, cloud isolada) — documentar | Em geral sob seu controle; validar imagens, hosts e partners | Seus hosts, GPU cloud, logging, embedding DB — inventariar |
Quando o caso tocar titular (ex.: RH, atendimento interno com PII), amarre Art. 20 / RIPD / ANPD como nas âncoras 01–03 — copiloto de suíte não dispensa essa leitura.
Cenários de decisão (heurísticas)
| Situação | Shortlist inicial típico |
|---|---|
| Microsoft 365 dominante; meta = produtividade transversal | Microsoft 365 Copilot primeiro; LLM enterprise como complemento para bolsões |
| Google Workspace dominante | Família Google Workspace/Gemini; API/Vertex se houver casos avançados |
| Forte time de P&D/eng; casos de análise e código | Claude Enterprise (ou peer) + integração; suíte copiloto opcional |
| Dados altamente sensíveis / requisitos de isolamento | Self-host ou VPC dedicada; ou enterprise com cláusulas e arquitetura revisadas por segurança |
| Orçamento apertado + higiene de dados ruim | Antes de qualquer copiloto: classificar dados e limpar permissões; senão a IA amplifica vazamento ACL |
| Quer agentes de processo (ERP/CRM), não só resumo de e-mail | Não pare em copiloto de suíte: veja orquestração (âncora 03) |
Copiloto de suíte ≠ plataforma de agentes
Erro clássico de buyer: achar que comprar Copilot/Gemini resolve inventário, Shadow AI, WhatsApp e bots de atendimento. São camadas diferentes.
Comprar um copiloto de produtividade não resolve Shadow AI nem inventário de agentes. Seats licenciados na suíte não registram bots de WhatsApp, automações no-code com API keys, plugins OAuth nem PoCs de times com LLM desacoplado. Sem inventário, owners e gate de go-live (âncoras 01–02), o copiloto até convive com Shadow AI — e às vezes o estimula, se a política oficial for só “temos Copilot, o resto é proibido” sem alternativa governada.
- Copiloto de produtividade: acelera o trabalhador do conhecimento sob permissões individuais.
- LLM enterprise/API: matéria-prima e workspace de raciocínio.
- Orquestração de agentes: ação em sistemas com tools e políticas.
- CX/WhatsApp: canal e operação de atendimento (âncora 04).
Um programa enterprise maduro combina camadas com owners distintos.
Programa de adoção (90 dias, modelo)
Dias 0–15: hipóteses de valor por área (jurídico, vendas, finanças, engenharia); riscos; grupos piloto; baseline qualitativo de tarefas.
Dias 16–45: piloto com champions; políticas de dados (“o que não colar”); office hours; coleta de fricções.
Dias 46–75: medir uso útil (não só seats ativos): templates, cenários, incidentes de dados; decidir expansão.
Dias 76–90: decisão de scale, complementos (API/agents), e backlog de higiene de conteúdo.
Sem higiene de permissões em repositórios, copiloto enterprise vira mecanismo eficiente de descoberta de dados mal classificados.
Perguntas obrigatórias ao fornecedor / parceiro
- O que acontece com prompts e arquivos no plano contratado (retenção, treino, subprocessadores)?
- Como a ferramenta herda ACLs do meu tenant?
- Quais logs admin existem e por quanto tempo?
- Como desligo por grupo / unidade?
- Qual o caminho para connectors e agents, e qual o modelo de responsabilidade compartilhada?
- Qual o processo de mudança de modelo e comunicação ao cliente?
- Quais certificações e laudos — e o que não cobrem?
Exija respostas escritas alinhadas ao SKU cotado.
FAQ
Devemos padronizar em um único vendor de IA?
Não obrigatoriamente. Muitos padronizam a camada de produtividade no ecossistema dominante e mantêm liberdade na camada de modelos/API para casos específicos. Documente a política para evitar Shadow AI.
Open-source é sempre mais barato?
Não. Licença de software pode ser zero e o TCO alto (GPU/API, gente, avaliação, suporte). Calcule operação.
Claude Enterprise substitui Microsoft 365 Copilot?
Em geral, não como substituto 1:1 da experiência embutida nos apps Office. Pode complementar ou atender bolsões. Avalie superfície de trabalho.
E se temos Microsoft e Google misturados?
Escolha a âncora pelo centro de gravidade dos dados e da identidade, ou aceite dois copilots com governança dupla (mais caro e mais complexo).
Quando self-host é justificável?
Quando requisitos de isolamento/controle e escala de uso interno superam o custo de operar qualidade e segurança — validado por CISO e plataforma, não só por preferência ideológica.
Disclaimer editorial
Guia informativo da iab2b.site. Não é endosso, ranking nem resultado de teste hands-on completo. Nomes de produtos e famílias são referências de mercado sujeitas a mudança de SKU e feature. Preços, cláusulas de treino de modelo, residência de dados e certificações devem ser verificados nos contratos e na documentação vigentes antes de decisão de compra ou republicação.