Confiança + Arquitetura
Construído para compradores industriais que não podem se dar ao luxo de surpresas.
A IA industrial é julgada pelo pior dia, não pelo melhor. A arquitetura da KPT é desenhada em torno da pergunta que todo plant manager realmente faz: "qual é o pior cenário se isso se comportar mal?"
Esta página é lida de cima para baixo, mas está estruturada para três audiências: stakeholders corporativos, engenheiros de planta + processo, e times de TI + segurança. Pule para sua seção se estiver com pouco tempo.
Para stakeholders corporativos
Seis promessas que a KPT faz para cada comprador.
Os inegociáveis. Eles vivem em nossos contratos como garantias, não como claims de marketing.
IA glass-box, não regras black-box
Cada variável que a KPT promove vem com uma explicação legível por humanos: quais features impulsionaram o lift, o que diz o contrafactual, o que o próximo experimento testaria. Podemos mostrar ao operador por que o modelo está recomendando uma mudança antes de ele aprovar.
Porta de confiança shadow-run de 30 dias
Cada variável que a KPT ativa foi A/B-testada contra seus dados reais por no mínimo 30 dias, com significância estatística antes da promoção. Compradores industriais temem 'e se piorar as coisas?' — construímos a resposta dentro do produto.
Cloud + On-Prem, um único codebase
A KPT roda como SaaS multi-tenant em lighthouse.kpt.tech E como container on-prem no seu datacenter. Mesmo motor de otimização, mesma UX, mesma cadência de releases. O aprendizado cross-deployment acontece via padrões federados, nunca com dados crus.
Gravações planner-in-the-loop
A KPT nunca grava no seu ERP / MES sem aprovação humana explícita. As recomendações fluem por uma UI de revisão; os planejadores auditam, sobrescrevem ou aprovam. O sistema de registro continua sendo o sistema de registro.
Isolamento de dados por tenant
Tenants cloud vivem atrás de políticas de row-level security e autenticação gerenciada. Tenants on-prem recebem uma chave de criptografia controlada pelo tenant — a KPT não consegue descriptografar o fine-tune do modelo local mesmo com um comprometimento total da infraestrutura.
Sem customização de ERP, MES, WMS ou TMS necessária
A KPT se sobrepõe aos seus sistemas core existentes — ERP (SAP, Oracle, Dynamics), MES, WMS, TMS — via APIs padrão. Nunca modificamos a configuração do seu sistema de registro. Seu stack core permanece limpo, audit-friendly e migration-safe.
Atualização: conheça como a KPT integra com o SAP S/4HANA — hoje, em 90 dias e certificado.
Para engenheiros de planta + processo
O que realmente significa no chão de fábrica.
As quatro decisões de design que determinam o que acontece no seu turno quando a KPT recomenda uma mudança — ou quando a própria KPT tem um dia ruim.
Porta de promoção
30 dias, significância estatística, depois live
Cada nova variável entra em um shadow run: a KPT computa a recomendação mas não a aplica. Trackeamos a recomendação contra o que realmente aconteceu na sua linha por 30 dias. Só variáveis que batem o baseline com significância estatística graduam para LIVE — e você vê todo o histórico A/B antes do botão de promoção ser habilitado.
Caminho de gravação
Os planejadores aprovam. Sempre.
Mesmo uma variável LIVE não auto-grava. A KPT gera uma mudança recomendada; seu planejador a vê na fila de revisão com a explicação e o impacto projetado; ele aprova, sobrescreve ou rejeita. A gravação só acontece após essa aprovação — e a decisão é logada com o nome do planejador.
Modo de falha
Se a KPT se comportar mal, nada quebra
A KPT é uma camada que propõe mudanças. Seu ERP / MES / WMS / TMS existente continua rodando exatamente como rodava antes da KPT ser instalada. Se cairmos, sua planta roda nos mesmos workflows de ontem — simplesmente paramos de enviar recomendações até voltarmos. Não há caminho crítico através da KPT.
Três formatos de deployment
Cloud SaaS, cloud isolado, ou container on-prem
PoC e times small-mid rodam em nosso cloud compartilhado com armazenamento de banco tenant-isolated. Clientes enterprise recebem lanes de compute isolados (boundary de rede separado, opcionalmente banco separado) na mesma plataforma gerenciada. Sites altamente regulados ou air-gapped rodam um container assinado em seu próprio datacenter — os dados crus nunca saem da sua rede.
Para times de TI + segurança
Proteção de dados, por arquitetura.
Quatro garantias sobre isolamento de dados + aprendizado federado, mais seis camadas de postura de segurança padrão. Revisável pelo seu time de compliance; executável por auditoria.
Dados crus nunca saem das suas instalações (modo on-prem)
Quando a KPT é implantada on-prem, o agente não tem endpoint outbound capaz de exportar leituras de sensores, eventos de MES, parâmetros de receita ou qualquer telemetria operacional. O tráfego outbound é restrito a uma allowlist hardcoded: atualizações de software assinadas do release registry da KPT, warm-starts de modelos federados no boot do agente, e (somente opt-in) atualizações criptografadas agregadas para a federação. A allowlist é executável por auditoria e está publicada na nossa documentação contratual.
Nenhuma parte individual — incluindo a KPT — vê os gradientes individuais de um cliente
Quando você opta pelo aprendizado federado de padrões, seu agente envia atualizações de gradiente DP-noised ao coordenador da KPT. O coordenador roda agregação segura: um protocolo criptográfico que soma atualizações de todos os clientes opted-in sem descriptografar nenhuma contribuição individual. Os engenheiros da KPT veem apenas o modelo federado agregado — nunca suas atualizações individuais. Isso é matematicamente garantido pelo protocolo, não apenas um compromisso de política.
Estatísticas agregadas carregam ruído de privacidade diferencial
Os agregados cross-customer que a KPT publica (por exemplo, "através dos nossos clientes de confeitaria, variáveis de tempo de mistura tiveram média +0.5% de melhoria de yield") são gerados apenas quando ao menos cinco tenants contribuíram E somente depois que um termo de ruído calibrado é adicionado. O ruído é dimensionado para um orçamento formal de privacidade diferencial trackeado por publicação. Mesmo um adversário com conhecimento auxiliar de todos exceto um tenant não consegue reverse-engineerar a contribuição do tenant retido a partir de qualquer número de agregados que publicarmos.
Cada padrão cross-tenant que chega à tela de outro cliente foi revisado por um engenheiro nomeado da KPT
Quando a variável de um cliente gradua para LIVE e passa de um limiar de impacto, o sistema a propõe como arquétipo generalizável para o KPT Commons (a biblioteca de padrões compartilhada). Antes desse arquétipo ser publicado, um engenheiro de processos da KPT o revisa: abstrai a variável para que seja despojada de qualquer detalhe identificador do tenant, generaliza suas precondições, e decide se ela faz merge em um arquétipo existente, vira um novo, ou é rejeitada como tenant-específica. O log de revisão lista o nome do engenheiro, a data e a decisão de abstração.
Postura de segurança padrão
Seis camadas que seu time de segurança vai reconhecer.
Identidade e acesso
Provedor de identidade gerenciado, tokens de sessão baseados em JWT, refresh-rotation em cada request autenticado, MFA-ready. O role-switching de staff interno para um tenant de cliente é gateado e logado com a identidade do membro do staff, o tenant de origem, o tenant de destino e o timestamp.
Isolamento de dados
Políticas de row-level security no banco gerenciado executam o filtro por tenant na camada de armazenamento. Uma cláusula WHERE esquecida em código de aplicação não consegue vazar dados entre tenants — o banco recusa. Leituras cross-tenant são matematicamente impossíveis sem um policy override explícito (que ele mesmo é auditado).
Edge de rede
TLS 1.2+ em todo lugar, HSTS, emissão de certificados CAA-pinned restrita a uma única CA confiável, proteção DDoS automática no edge do CDN. Sem API keys de longa vida em contexto do navegador; todas as chamadas privilegiadas fluem pela camada de identidade gerenciada.
Segredos e criptografia
Os segredos da aplicação vivem em um vault gerenciado e rotacionam em um cronograma fixo; sem chaves de longa vida no código-fonte, em arquivos env ou no CI. Dados em repouso usam AES-256 na camada de armazenamento. Deployments on-prem recebem uma chave controlada pelo tenant para que a KPT não consiga descriptografar o fine-tune do modelo local mesmo com um comprometimento total da infraestrutura.
Audit log
Append-only por tenant. Cada ação que muda estado — promoção de variável, demoção, mudança de assinatura, switch de tenant de staff KPT, aprovação de sugestão, reset de senha — escreve uma linha imutável com o ator, o sujeito e os metadados. O log sobrevive a reinícios de container, rebuilds de infraestrutura e migrações. Clientes enterprise podem exportar seu audit trail completo a qualquer momento.
Política de migração never-erase
Cada migração de banco é aditiva por default. Operações destrutivas exigem um header BACKWARD_INCOMPATIBLE explícito no docstring da migração com uma justificativa escrita. O CI bloqueia qualquer migração sem ele de chegar à produção. Combinado com snapshots automáticos pré-migração, os dados do cliente não podem ser perdidos por ação de engenharia.
Para engenheiros
Arquitetura, em padrões.
Detalhe suficiente para seu time de engenharia avaliar a KPT competentemente — não o suficiente para um concorrente clonar a cola de integração. Nomes específicos de fornecedores, IDs de serviço e detalhes de config vivem em docs gateados por NDA que compartilhamos durante a revisão de segurança.
Ingestão
Os conectores puxam do seu ERP / MES / WMS / TMS em um cronograma que você controla. Validação + normalização + tenant-tagging acontecem no boundary; o input cru nunca é confiado as-is rio abaixo.
Isolamento de tenant
Cada request carrega um tenant claim, setado como variável de sessão de banco na entrada. As políticas de RLS em cada tabela customer-scoped executam o filtro. O caminho de código da aplicação não executa o tenant scoping — o banco sim.
Motor de otimização
Solver de restrições multivariado (CP-SAT + branch-and-bound custom para os edges pesados) sobre toda sua superfície de variáveis, mais uma camada ML de descoberta de padrões que propõe novas variáveis, mais um estágio LLM-assisted de sugestão de variáveis para input em linguagem natural do operador. Stateless — cada rodada é reproduzível a partir dos inputs.
Porta de promoção
O harness shadow-run registra a recomendação do modelo junto com o outcome real por no mínimo 30 dias. As variáveis só graduam quando o lift é estatisticamente significativo. A porta é parte do motor, não um check rio abaixo.
UI do planejador
Apresentação glass-box de recomendações: quais variáveis impulsionaram a mudança, o que diz o contrafactual, o que o próximo experimento testaria. O planejador aprova, sobrescreve ou rejeita. A decisão é logada com a identidade do planejador antes de qualquer write-back.
Write-back
APIs padrão para seu ERP / MES / WMS / TMS — sem customização do seu lado, sem mudanças de schema. As gravações são gateadas atrás da aprovação do planejador e auditadas. Se seu sistema de registro recusar a gravação, a recomendação fica parqueada, não perdida.
Tracking de impacto
Camada de atribuição de KPI mede o delta real entre janelas KPT-on e KPT-off para cada variável promovida. Alimenta o leaderboard que os clientes veem; alimenta os contratos que assinamos (somos pagos por impacto medido, não por vibes).
O que NÃO está no stack
Cinco coisas que deliberadamente não fazemos — geralmente a segunda pergunta que revisores de segurança fazem.
- × Analytics ou session-replay trackers de terceiros em dashboards de clientes.
- × Chamadas outbound para a KPT durante modo on-prem que não estejam na allowlist publicada.
- × Dados crus do cliente fluindo para provedores LLM — apenas metadados abstratos de variáveis fluem.
- × Um pipeline de "melhoria de modelo" que scrapeia dados do cliente sem opt-in explícito.
- × Staff da KPT com acesso permanente a dados do cliente. O acesso é role-switched + logado por sessão.
IDs específicos de fornecedor + serviço, version pinning e suítes de testes de integração são compartilhados sob NDA mútuo padrão durante a revisão de segurança. Contate security@kpt.tech para solicitar o pacote.
Como engajar
Para revisão mais profunda.
Suportamos a maioria dos processos formais de revisão que os times enterprise de TI e compliance usam, com base em NDA mútuo padrão.
Questionários de segurança. Respondemos os comuns (CAIQ, SIG, formulários internos customizados) em 5 dias úteis para oportunidades ativas.
Revisão SOC2-readiness. Compartilhamos nosso mapeamento de controles atual, análise de gaps e timeline de remediação. A atestação SOC2 Type 2 está no roadmap 2026.
Auditoria de penetração de terceiros. Clientes enterprise podem rodar um pen test one-time no ambiente de staging ou contratar seu auditor preferido para um escopo anual. Fornecemos a superfície de teste + SLA de remediação.
Termos contratuais customizados. Opt-out de aprendizado federado, compromissos de residência de dados, janelas de notificação de breaches e direitos de auditoria são negociáveis no MSA enterprise.
Confiança não é uma feature
É a arquitetura inteira.
A porta de confiança shadow-run de 30 dias, a IA glass-box, o caminho de gravação planner-in-the-loop, o isolamento de dados por tenant — esses não são bullets de vendas. São a resposta para a única pergunta que importa em IA industrial: o que acontece quando ela se comporta mal?