A maior parte da linha AI Suite instala-se na própria máquina do usuário. Não há locatário. Não há login na nuvem que restrinja o acesso ao motor de inferência. Os aplicativos para desktop comunicam-se com um aisuite-server processo que, por sua vez, conversa com um modelo local ou com um AI Server controlado pelo cliente e executado dentro da rede do cliente. Essa escolha — instalador para desktop, não SaaS — é deliberada, e as razões valem a pena serem registradas.

Razão 1: compradores regulados não podem colocar prompts de produção na nuvem de terceiros

O Regulamento de IA da UE, em vigor desde 2024, classifica um conjunto substancial de fluxos de trabalho empresariais como "de alto risco" e impõe obrigações de registro, supervisão humana e tratamento de dados ao implantador [1]. Estruturas equivalentes ou paralelas existem nos países membros da OCDE [2], e agências federais dos EUA operam conforme o NIST AI Risk Management Framework ao adquirir sistemas de IA [3]. Nenhuma dessas estruturas proíbe IA na nuvem; elas exigem que o implantador possa demonstrar, contemporaneamente e sob demanda, o que foi enviado para onde e o que retornou.

Na prática, esse requisito colide com o funcionamento atual das APIs de LLM na nuvem. Um responsável por conformidade farmacêutica não pode extrair um histórico de auditoria por prompt de um SaaS de terceiros para um fluxo de trabalho que processa identificadores de pacientes, mesmo quando o SaaS está contratualmente alinhado ao GDPR. Pode ser necessário que o prompt e a resposta nunca saiam de uma rede que eles possuam. A forma mais limpa de garantir esse caminho é entregar a IA como um binário que o cliente executa dentro do seu próprio perímetro — que é o que fazemos.

Este não é um comprador hipotético. O grupo de clientes para o qual entregamos desde 2007 inclui seis organizações Fortune Global 500 nos setores farmacêutico, financeiro, governamental, jurídico, de defesa e energético [4]. Cada um desses setores tem pelo menos um fluxo de trabalho onde a resposta para "onde ocorre a inferência?" decide se a conversa de aquisição sequer começa.

Razão 2: um binário instalável corresponde à forma como as empresas realmente compram software

O processo de compra de um aplicativo para desktop é bem compreendido dentro de grandes organizações de TI. O aplicativo é empacotado, distribuído via SCCM, Intune ou Jamf, governado pelas mesmas políticas de grupo do Microsoft Office, removido quando o laptop é desativado. Aquisição, revisão de segurança e computação do usuário final têm processos com décadas para isso. AI Suite se encaixa diretamente.

SaaS na nuvem, por outro lado, requer um processo paralelo: revisão de risco do fornecedor por locatário, conversa sobre federação de identidade, auditorias contínuas da postura do fornecedor e uma negociação constante sobre quem cobre o quê quando algo falha. Útil para alguns tipos de software. Não adequado para os tipos de fluxos de trabalho de IA que nossos clientes estão construindo.

Ao entregar aplicativos instaláveis que podem autenticar-se no próprio provedor de identidade do cliente — Microsoft Entra ID ou Google Workspace via OpenID Connect — mantemos o conteúdo da inferência fora do plano de controle da Software Tailor. Os serviços da organização ainda processam os registros necessários para operar a implantação: lista e funções, direitos, políticas e estado do servidor, uso agregado, auditoria administrativa, licenciamento e suporte. Esses são registros reais do lado do fornecedor, mas estão separados dos prompts, respostas e documentos do cliente no caminho do modelo local ou hospedado pelo cliente.

Razão 3: zero falhas em projetos desde 2007 depende de não depender da disponibilidade de terceiros

Entregamos software personalizado há dezenove anos com um histórico de zero falhas em projetos desde 2007 [4]. Esse histórico existe porque a equipe controla todas as camadas da entrega: código, compilação, teste, artefato de implantação. No momento em que fazemos o fluxo de trabalho de produção de um cliente depender da disponibilidade da nuvem de outra empresa, esse histórico deixa de ser nosso para defender.

Fornecedores de IA na nuvem têm interrupções. Eles limitam o uso. Mudam preços. Descontinuam modelos. Descontinuam APIs inteiras. Clientes que atendemos nos setores farmacêutico e de defesa não podem ter seus processos regulatórios de anos paralisados porque um endpoint de modelo que não possuem foi migrado. Portanto, não colocamos o caminho do modelo local deles em um desses. O modelo reside no equipamento do cliente e a inferência ocorre no equipamento do cliente. Nossa infraestrutura fornece os serviços do plano de controle necessários para identidade, direitos, políticas, estado da frota, uso agregado, administração e suporte; não é o runtime de inferência e não recebe conteúdo de prompt ou resposta nesse caminho.

O que isso significa para avaliação

Se você é um responsável por conformidade, um CIO ou um CTO avaliando IA local para uma implantação empresarial, as perguntas relevantes são diferentes das de uma avaliação de SaaS na nuvem:

  • Onde ocorre a inferência? No dispositivo do usuário, ou em um servidor controlado pelo cliente. Não no nosso.
  • O que sai do perímetro? No caminho de inferência local ou hospedado pelo cliente, nenhum prompt, resposta ou conteúdo de documento vai para a Software Tailor. Registros do plano de controle, licença, segurança, telemetria (quando ativada) e suporte têm caminhos de dados documentados e separados.
  • Qual é o rastro de auditoria? JSONL sem conteúdo, armazenado localmente, exportável. O modelo nunca vê conteúdo que não foi instruído a processar, e a linha de auditoria nunca vê conteúdo algum.
  • O que acontece quando o fornecedor desaparece? Binaries instalados e o runtime local gratuito não dependem de um tenant de inferência hospedado. Assinatura, organização e capacidades Pro gerenciadas centralmente ainda podem depender de direitos válidos e serviços do plano de controle, portanto um plano de saída deve considerá-los.

Essas são as quatro perguntas que construímos AI Admin Console e o Local AI Suite para responder claramente. O artigo sobre conformidade com o EU AI Act e implantação on-premises aborda o lado regulatório com mais profundidade.

Referências

  1. Comissão Europeia. "AI Act — Quadro regulatório sobre IA." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Acesso em 15-06-2026.
  2. Observatório de Políticas de IA da OCDE. "Políticas nacionais de IA." https://oecd.ai/. Acesso em 15-06-2026.
  3. NIST. "Estrutura de Gestão de Riscos de IA (AI RMF 1.0)." https://www.nist.gov/itl/ai-risk-management-framework. Acesso em 15-06-2026.
  4. Software Tailor. "Clientes anteriores." https://softwaretailor.com/past-clients.htm. Acesso em 15-06-2026.