Porque entregamos a IA como binários instaláveis e não como SaaS em nuvem

A maior parte da gama AI Suite instala-se na máquina do próprio utilizador. Não há tenant. Não há login na nuvem que limite o acesso ao motor de inferência. As aplicações desktop comunicam com um processo aisuite-server local que, por sua vez, comunica com um modelo no próprio dispositivo ou com um AI Server controlado pelo cliente, em execução dentro da rede do cliente. Essa opção — instalador de desktop, não SaaS — é deliberada, e as razões valem a pena ser postas por escrito.

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

O EU AI Act, em vigor desde 2024, classifica um conjunto substancial de fluxos de trabalho empresariais como "de alto risco" e impõe obrigações de manutenção de registos, supervisão humana e tratamento de dados ao deployer ^[1]. Quadros equivalentes ou paralelos existem nos Estados-Membros da OECD ^[2], e as agências federais dos EUA operam segundo o NIST AI Risk Management Framework quando adquirem sistemas de IA ^[3]. Nenhum destes quadros proíbe a IA em nuvem; exigem que o deployer consiga demonstrar, em contemporâneo e pedido a pedido, o que foi enviado para onde e o que retornou.

Na prática, esse requisito colide com o modo como as APIs de LLM em nuvem funcionam hoje. Um responsável de conformidade farmacêutico não consegue extrair um registo de auditoria por prompt de um SaaS de terceiros para um fluxo de trabalho que processa identificadores de doentes, mesmo quando o SaaS está contratualmente alinhado com o RGPD. Precisam que o prompt e a resposta nunca saiam de uma rede que lhes pertence. A forma mais limpa de lhes dar isso é 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 conjunto de clientes que servimos desde 2007 inclui seis organizações da Fortune Global 500 nos setores farmacêutico, financeiro, governamental, jurídico, defesa e energia ^[4]. Todos esses setores têm pelo menos um fluxo de trabalho em que a resposta à pergunta "onde acontece a inferência?" decide se a conversa de aquisição sequer arranca.

Razão 2: um binário instalável encaixa na forma como as empresas compram software, na prática

O circuito de compra de uma aplicação desktop é bem conhecido dentro de grandes organizações de TI. A aplicação é empacotada, distribuída via SCCM, Intune ou Jamf, regida pelas mesmas políticas de grupo do Microsoft Office, removida quando o portátil é desativado. Compras, revisão de segurança e end-user computing têm todos processos com décadas para isto. O AI Suite encaixa-se diretamente.

O SaaS em nuvem, em contrapartida, exige um circuito paralelo: uma análise de risco do fornecedor por tenant, uma conversa de federação de identidade, auditorias contínuas à postura do fornecedor e uma negociação constante sobre que obrigações cobrem o quê quando algo corre mal. Útil para alguns tipos de software. Mau encaixe para o tipo de fluxos de trabalho de IA que os nossos clientes estão a construir.

Ao entregarmos aplicações instaláveis que se autenticam contra o próprio fornecedor de identidade do cliente — Microsoft Entra ID ou Google Workspace via OpenID Connect — e que nada armazenam nos nossos servidores para além da lista de pessoas da organização e do registo de auditoria das ações administrativas, colocamos a conversa de compras na caixa que ela já sabe processar.

Razão 3: zero falhas de projeto desde 2007 depende de não depender do uptime de outra pessoa

Entregamos software à medida há dezanove anos com um registo de zero falhas de projeto desde 2007 ^[4]. Esse registo existe porque a equipa controla todas as camadas da entrega: código, build, testes, artefacto de implantação. No momento em que tornamos o fluxo de trabalho de produção de um cliente dependente da disponibilidade da nuvem de outra empresa, esse registo deixa de ser nosso para defender.

Os fornecedores de IA em nuvem têm interrupções. Aplicam throttling. Alteram preços. Descontinuam modelos. Descontinuam APIs inteiras. Os clientes que servimos no setor farmacêutico e na defesa não podem ter o seu processo regulatório de um ano travado porque um endpoint de modelo que não lhes pertence foi migrado. Por isso, não os colocamos num. O modelo vive na máquina do cliente, a inferência acontece na máquina do cliente, e a única coisa na nossa infraestrutura é a superfície de administração leve que utilizam para gerir a sua própria implantação.

O que isto significa para a avaliação

Se é um responsável de conformidade, um CIO ou um CTO a avaliar IA local para uma implantação empresarial, as perguntas relevantes têm um aspeto diferente do de uma avaliação de SaaS em nuvem:

• Onde acontece a inferência? No dispositivo do utilizador ou num servidor que o cliente controla. Não no nosso.
• O que sai do perímetro? Apenas a lista de pessoas da organização e as ações administrativas. Nenhum prompt, nenhuma resposta, nenhum conteúdo de documentos.
• Qual é o rasto de auditoria? JSONL sem conteúdo, armazenado localmente, exportável. O modelo nunca vê conteúdo que não lhe seja indicado para atuar, e a linha de auditoria nunca vê conteúdo de todo.
• O que acontece quando o fornecedor desaparece? Os binários que o cliente instalou continuam a funcionar. O AI Server local que registou continua a servir. Não é necessária replataforma.

Estas são as quatro perguntas para as quais construímos o AI Admin Console e o Local AI Suite de modo a responder com clareza. O artigo sobre conformidade com o EU AI Act e implantação on-prem aborda o lado regulatório com mais profundidade.

Referências

1. Comissão Europeia. "AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu. Acedido a 2026-06-15.
2. OECD AI Policy Observatory. "National AI policies." oecd.ai. Acedido a 2026-06-15.
3. NIST. "AI Risk Management Framework (AI RMF 1.0)." nist.gov/itl/ai-risk-management-framework. Acedido a 2026-06-15.
4. Software Tailor. "Past clients." softwaretailor.com/past-clients.htm. Acedido a 2026-06-15.

Artigos relacionados

• Zero falhas de projeto desde 2007 — as regras de engenharia que sustentam o registo
• Porque é que as implantações de IA on-prem ficam paradas em compras (e o enquadramento que resolve a situação)
• EU AI Act em 2026: o que a implantação on-prem altera em matéria de conformidade
• Todos os artigos →